Solved: VCS Expressway & Control - AD Authentication - Page 2

tphamaccudata · ‎08-22-2011

Does anyone have this working where a MOVI user is able to authenticate remotely via Proxy from the VCS Exp to the VCS Control that is AD Authenticated? We have it AD Auth working perfectly when the user is in the office, however, the registration just hangs once they are out of the office. Here is our setup:

VCS Control (x6.1) configured as vcsc.example.com

TMS (13.1) configured as tms.example.com

VCS Exp (x6.1) configured as vcse.example.com

Inbound and outbound calls (to internal and B2B) work perfectly for SIP and H323 endpoints. I just cannot get devices to register properly on the VCS Ctrl.

I have the neighbor zone configured and it is showing all greens. I set the VCS Exp default zone as Do not Check Creds and the same for the Default Subzone. On the VCS Ctrl I have it to check creds on the Default Zone and Default Subzone.

I have tried several other variations based on some of the threads in here, but no success. ASA Firewall has SIP inspection turned off, and I do not see any blocks on the logs.

Any help is appreciated!

Thang

abdelkader amghar · ‎09-15-2011

Hello Andreas,

I've just to make test in two environnment AD authentification and provisioning authentification for extermal movi users and now all is working fine.

Thanks you very much for your help

Abdel

Georg Kehrer · ‎09-16-2011

Hello to all

I have read all the post and I'm have just now the same Problem to make the right configuration for AD authentication ond the VCS-Expressway.

If I have seen that are different ways possbile.

But for me is interesting that I would like to know which user are registered on the VCS-Express regardless is a MOVI (SIP) user or VC endpoint with SIP/H323, and for all this VC's I would like Authenticate to AD

I think only SIP User can authenticate to AD (MOVI and E20)? also possible to authenticate with AD with the C-Codec with SIP Protocol?

Because on the VCS Expressway I would like to use Policy Rule to prevent ISDN GW Calls from Internet user (Atacks)

(at the moment the hackes are very agressive to use the VCS-E Boxes to us as Telephone GW)

So, If I configured on the VCS-E and VCS-C the follow Zone

VCS-C: traversal zone:check credential

Default Zone:threat as authentificated

DefaultSubzone:threat as authentificated

VCS-E traversal zone: do not check credential or threat as authentificated

Default Subzone on the VCS-E: check credential

Default zone: check credential

(create a Subzone "Internet User with memebrship rule for all user from internet) must be: check credential

Authentification VCS-C:local database or AD

Authentification VCS-E: local database (for C-Codec is the authentication on the local Database ?)
for MOVI via Traversal Link "check credential on" to VCS-C --> AD

I think with this configuration I have Security on the VCS-E to prevent unauthorized User to register on the VCS-E.

After that I can create the Policy Rule for the Security.

With this config can I get the Problem with the Presence Status for MOVI?

I couldn't test the Config at the moment, I'm next week on customer site to configure this.

Any Input are appreciated.

Thank you

Regards

Georg

joshuamarsh · ‎03-09-2012

Great discussion. Thanks, all. Andreas, +5.

We have external Movi clients registering to VCSE through VCSC via AD.

On VCSE our configuration follows:

DSZ: Do not check

TZ: Do not check

On VCSC

TZ: Check

DSZ: Treat as auth

We are seeing the issue you mention in your post, Andreas: "Please note that with the Default Subzone on the VCS-E set to 'Treat as authenticated', it means that normal non-provisioned endpoint will be able to freely register with the VCS-E." (I realize we are slightly different w/ our do not check on our VCSE, but we have reasons to not treat as auth there.)

Something doesn't feel right here. What is the best-practice? I'd ultimately like to have external Movi clients registering to VCSE via AD, and either do the same to external endpoints (or have a local authentication DB). Having any non-Movi endpoint able to register to VCSE w/o authentication seems like a bad idea. Are people allowing direct authentication from Expressway to AD through the firewall instead of proxying it through Control, so you can get a secure solution for all endpoints and not just Movi?

Thanks,

Joshua

aewillcox · ‎01-02-2013

It may be uncouth to bump such an old topic, but I'm in the exact same scenario as you describe with a client. I'm using settings identical to yours for zone credentials, but it's still not properly passing authentication. Logins work if I set everything to "Treat as Auth" but this is well covered and obviously not secure. I would like to keep the local subzone for Control as "Treat As Auth" as the internal network is considered trusted here, and it provides fewer points of failure for their central hardware endpoints.

The only difference between your configuration and mine would be software versions and perhaps the provisioning extension (rather than agents). I have a TAC case open but would love to hear some feedback from others who have tackled this recently.

joshuamarsh · ‎01-02-2013

Somebody from TAC (Zac) came up w/ a pretty cool solution. I haven't yet gotten this to work, but that's due to lack of effort and time on my part. One of these days, I hope to get the time to try this out. Here's a copy of his text. All credit goes to Zac for this one (thanks, Zac). I'd be curious to know if this works, so please let me know if you're successful.

The VCS Control would have Active Directory Service enabled and joined to the Active Directory Domain. For the VCS to authenticate Movi/Jabber credentials against AD before the SUBSCRIBE for provisioning is sent to the provisioning service, the Default Zone would be set for Check Credentials. For the SUBSCRIBE requests coming from the Expressway, the Traversal Zone on the VCS Control would also be set for Check Credentials. This will handle the authentication for provisioning. The next part is the registration of the Movi/Jabber client. The subzone that the client will register to also needs to be set for Check Credentials. This is all you need for internal registrations (registration at the VCS Control). For the Expressway, things get a little more complicated. For the provisioning subscription, the SUBSCRIBE is forwarded to the VCS Control. With the Traversal Zone on the VCS Control set for Check Credentials, you are all set. Now on to the registration to the Expressway. The subzone that the client will register to will need to be set for Check Credentials. Since the VCS Expressway does not have direct access to Active Directory, we need to utilize local credentials on the Expressway. A set of credentials will need to be configured in VCS Configuration > Authentication > Devices > Local Database. You will create a single name and password that all Movi/Jabber clients will use. The end user does NOT need to know of these credentials. The username and password is supplied to the Movi/Jabber client through the provisioning data that it has received. To configure that data, on the TMS, you need to configure a SIP Authentication Username and SIP Authentication Password in the provisioning configuration. For this options to be available, you need to make sure that you have uploaded the xml configuration template for the version of Movi/Jabber that you are using. The xml file is included with the full zip package of the client that can be downloaded from www.cisco.com. So that will take care of the Expressway registration. Now this creates an interesting situation with the VCS Control. The internal Movi/Jabber client will receive the same provisioning configuration, and will attempt to use those same credentials when registering to the VCS Control. The VCS Control is already set to authentication the registration request against Active Directory, and ONLY Active Directory. You will need to create an Active Directory account that matches those credentials. The Active Directory account does not need any special access. It is used for authentication purposes only. A few things to keep in mind: the SIP Authentication Username and SIP Authentication Password are stored in the provisioning configuration in clear text. That means that the data is sent in clear text. To be sure that this data is not compromised on the wire, be sure that you are using TLS for your Movi/Jabber SIP communication.

That’s it in a nutshell. I hope this explains the design that I have described to you.

aewillcox · ‎01-02-2013

Haha, I really like this. I would also like to try this configuraiton as a matter of interest, however this would not meet my client's requirements.

I would really like the configuration to look like this, as described in a Cisco signallying document. I had thought that configuring the VCS Control for direct authentication and then having a search all aliases rule would have provided this funcitonality. See attached.

joshuamarsh · ‎01-03-2013

From my understanding you are pointing to a significant shortfall on VCS security. I'm sure there is someone out there with some better ideas, but short of the TAC configuration above, I haven't seen a good way to secure this. My best idea is what I use in practice: cheesy, but it does provide some light modicum of security: