VCS Expressway & Control - AD Authentication

[tphamaccudata]

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

[Anthony Thomson]

I think you have it right in thinking that it's the authentication settings.

My default zone zone and traversal zone on both VCS-C and VCS-E are both set to "treat as authenticated", and I can log in to Movi via the VCS-E without issues.

[epicolo]

Hi Thang

So, when the same Movi client point to VCS Internal and register on VCS control everything goes fine (registered and authenticated), but when this client is in an external network and point to VCS External and try to register on VCS E the registration/authentication don´t work.

Did you tried to configure the VCS E with treat as authenticated and configured the VCS C neighbour zone as Trust Auth On?

PS: An external Movi will try to register on the VCS E, so, the authentication must be configured on VCS E subzone

Do a trace on the Movi client to check at wich point is failing and take a look at the event log.

*As a test only (curiosity), you could also try to remove the SIP domain on VCS E and configure Proxy to know only and on VCS C configure Accept proxied registrations, to sse if the registration/auth will be accepted on behalf of VCS E.

Please, post the solution when you findit.

Regards

[tphamaccudata]

Thanks everyone for your recommendations.  I tried those settings and they were unsuccessful.  Since there are so many areas to configure authentication, please let me know which configs you want to try:

VCS-E:

  Protocols->SIP->Configuration->SIP Registration Proxy Mode = Proxy to Any

  Authentication->Devices->Configuration = Local DB

  Local Zone->Default SubZone->Registration Policy = Allow

  Local Zone->Default Subzone->Authentication Policy = Do Not Check Creds (also tried Treat As Authenticated)

  Zones->Default Zone-> Do not Check Creds (also tried Treat As Authenticated)

  Zones->TraversalZone->Authentication Policy = Do Not Check Creds

  Zones->TraversalZone->Accept Proxy Reg = Allow

VCS-C:

  Protocols->SIP->Conf->SIP Reg Proxy mode = Proxy to Any

  Authentication->devices->config = LDAP (working with internally registered MOVI clients)

  Local Zone->Def Sub->Reg Policy = Allow

  Local Zone->Def Sub-> Auth policy = Check Creds

  Zones->Default Zone->Check Creds

  Zones->TraversalZone->Authentication Policy = Treat as Authenticated

  Zones->TraversalZone->Accept Proxy Reg = Allow

I've tried several scenarios as recommended, so let me know the specific one that you would like to see.  I can post MOVI logs if it will help.

Thanks again for your help.

Thang

[awinter2 · Accepted solution]

Hi Thang,

if you want the VCS-C to perform AD authentication for external Movi clients, you need to set the Traversal zone authentication policy on the VCS Control to 'Check credentials'. This means that when external Movi clients attempt to sign in via the Expressway by sending a SIP SUBSCRIBE message to the VCS-E, the VCS-E will forward this SUBSCRIBE to the VCS-C (assuming that you have configured the search rule(s) accordingly). When the VCS-C receives this SUBSCRIBE, which comes in on the traversal zone, the VCS-C will then challenge this SUBSCRIBE for credentials, since the traversal zone on the VCS-C is configured to do so. Assuming you are using Movi 4.2, Movi will attempt to use NTLM authentication and the VCS-C will then authenticate this SUBSCRIBE against AD.

In addition, I recommend that you set the Default Subzone on the VCS-E to 'Treat as authenticated', to ensure that presence will work properly for Movi clients (Presence PUBLISH messages from Movi need to be authenticated in order to be accepted by the presence server).

If you want the external Movi registrations to hang off the VCS-E, you should make sure to add the provisioning SIP domain to the VCS-E as well.

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.

If you can't get this working using the above pointers, I recommend that you raise a TAC case and provide the xconf, xstat, netlog 2 logs from both VCS's (Taken whilst attempting to sign in from an external location) so that we can troubleshoot this further for you.

Hope this helps,

Andreas

[tphamaccudata]

Thanks for the help Andreas.  Unforutnately the settings did not work, so I will put in a case with TAC.  I will update this thread with their recommendations.  In the mean time, if anyone else ha any other items they want me to try, I'll be glad to.

Thang

[tphamaccudata]

TAC Case opened, and they provided another document which I did not find on the Cisco / Tandberg Support site (I have attached it to this msg for anyone that needs it).  We utilized the Firewall Scenario 4 and now devices can register remotely.  One caveat is that we have to leave the Internal VCS field in MOVI as blank.  It registers fine in the office and outside of the office (and I have verified it is still checking against AD Auth in both cases).  However, now all my registrations for MOVI show up on the VCS-E whether I am in the office or out.  All calling features work fine inbound and outbound.  When I put my settings in the Internal VCS field, users can log in when they're in the office, but when they are outside, we get this error:

Login failed due to Technical Problems....blah blah blah contact IT Support.  In the VCS logs, it shows up as a 408 error.  I'm not sure if I keep troubleshooting this with TAC since my users are able to utilize the system.  Will let you know if we do find out the ultimate answer.  Any other thoughts or suggestions?

[joshuamarsh]

Thang, I'm not seeing your attachment.  Could you attach again please, or give document title?

[RICHARD MESSINGER]

I am running into a similar problem where the Movi Clients can register just fine inside the network to the VCS Controller but get rejected when registering to the VCS-E.  Getting error, Wrong Username, Domain or Password.

I am running 6.1 on both VCS's and 13.1 on my TMS server.  I have configured the VCS's as described in the on-line docs for 7.1.

It seems like the majic sauce for making this all work is missing.

Thanks

[Paul Woelfel]

Hi, I'm having similiar troubles, but I've already managed to authenticate users on the Expressway. The issue is, that if you enable authentication on the expressway on the default zone, the expressway won't sent the subscribe message to the control, if it can't authenticate the user. So the user must be available on the expressway. In the sales presentations it's always, as you only need 4 ports to foward signaling and media traffic aso, but if you'd like to authenticate movi users, you also need a LDAP connection to your TMS, to challenge the credentials.

So our basic setup is as following:

VCS Control internal with provisioning enabled

VCS Expressway DMZ

TMS syncing users from Active Directory, with SIPIdentity (also SIPIdentityPassword!)

To register to the expressway, you need to create the internal sip domain, i.e. example.int, also on the expressway and add the TMS as LDAP authentication under VCS Config -> Authentication -> Device -> LDAP Configuration and enable authentication against the LDAP Database. The TMS replication user is needed to successfully establish a connection.

So if a movi user tries to register to the expressway from the public internet, he will be challenged from the expressway, and authenticated to the LDAP provisioning database of the TMS. Then the provisioning request will be forwarded to the Control to get the provisioning settings. This request will be challenged by the TMS Agent of the VCS Control.

Our authentication policies are set as follows:

VCS Control:

DSZ: Treat as authenticated

DZ: Do not check credentials

Traversal Zone: Do not check credentials

VCS Expressway:

DSZ: Check credentials

DZ: Check credentials

Traversal Zone: Do not check credentials

VCSC and VCSX Taversal:

Accept proxied registrations: Allow

SIP has to be enabled on the Traversal Client & Server, otherwise the provisioning request can't be forwarded.

on VCSX: VCS Config -> SIP -> configuration

SIP registration proxy mode: Proxy to Any

on the VCSX you need a search rule for your internal domain, which will also be used to forward provisioning requests (provisioning@example.int)

Search name: traversal zone search internal domain

Source: Any

Authentication required: no

Regex ^(.*)@example\.int$

Pattern behaviour: leave

Target: TraversalZone

With that config I'm able to register movi clients over the Expressway. What I'm currently checking with TAC, if it's possible to use NTLM authentication. The issue is, that the Expressway can't challenge NTLM, unless the Expressway is a member of Active Directory. So it is only possible to use authenticate against TMS credentials and not against AD credentials.

This is not the magic souce, but maybe some of the spicery could be found in it

[tphamaccudata]

Paul,

  I am now able to get both Exp and Ctrl Movi clients to register via NTLM AD Authentication using the settings that Andreas recommended.  I also resolved my issue of having to leave the internal VCS field to blank with the upgrade to 7.X of VCS Ctrl and Exp.  I attached the VCS Static NAT document that I refered to earlier (I am using Static NAT scenario 4).  So far everything is registering / performing as expected....the guides definitely need to be refined and updated, as this whole process was much more tedious than it needed to be.

Message was edited by: Vinay Sharma

[Marwan ALshawi]

Andreas,

I am just confusing here between provisioning authentication and the vas-c ad authentication ? If I have a user created for movi in ad and imported by tms will the authentication be checked against vcs or tms to AD as I know with previous versions the tms generate random password for AD accounts

Thanks,

[awinter2]

Hi Marwanshawi,

if the VCS is configured for AD authentication for Movi users (According to the 'Authenticating devices' deployment guide), and if using Movi 4.2 or newer, the Movi credentials will be authenticated towards AD rather than towards the randomly generated passwords located in the provisioning back-end.

Best regards

Andreas

[abdelkader amghar]

Hello Andreas,

I've try the setting you said in the precedent post:

VCS-C: traversal zone:check credentiel

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: 'Treat as authenticated

Default zone:check credentiel orTreat as authenticated

Authentification VCS-C:local database or AD

Authentification VCS-E:local database

When I use active directory authentification or password located in the provisionning from my external MOVI clients.It seems that any password can works therefore we don't have authentification. Can you explain me what I need to enable for the VCS-E ask the credential put on my movi to the VCS control? In you post you said just enable traversal zone on the VCS-C but maybe I forgot something.

Thanks you by advance,

external Movi clients, you need to set the Traversal zone  authentication policy on the VCS Control to 'Check credentials'. This  means that when external Movi clients attempt to sign in via the  Expressway by sending a SIP SUBSCRIBE message to the VCS-E, the VCS-E  will forward this SUBSCRIBE to the VCS-C (assuming that you have  configured the search rule(s) accordingly). When the VCS-C receives this  SUBSCRIBE, which comes in on the traversal zone, the VCS-C will then  challenge this SUBSCRIBE for credentials, since the traversal zone on  the VCS-C is configured to do so. Assuming you are using Movi 4.2, Movi  will attempt to use NTLM authentication and the VCS-C will then  authenticate this SUBSCRIBE against AD.

[awinter2]

Hi Abdelkader,

you shouldn't have your Default Zones set to 'Treat as authenticated', these should be set to 'Do not check credentials' on the VCS-E and 'Check credentials' on the VCS-C.

If these are set to 'Treat as authenticated', any incoming message to this zone will be tagged as authenticated, and thus allowing any Movi user to log in regardless of the password.

Hope this helps,

Andreas