We have two groups of Jabber Video users within our TMS, each having their own type of account.
We currently have a VCS Control and are implementing and Expressway later this year.
Is it possible to do either of the two options with the VCS-C/E?
Obviously option #1 would be prefered to keep everything under the same domain. The big question is, how to accomplish either option, whichever is capable of being done.
TMS, TMSPE, VCS all running current software release.
Solved! Go to Solution.
So you do not want to use a unified SIP domain? For external AD users, the provisioning config is a bit different for the norm. You would need to make use of the SIPAuthUsername and SIPAuthPassword configuration settings in the Provisioning. I have written up an explaination of this. Keep in mind that this is only part of the puzzle for the complete solution. I referrance below that on AD credentials work on the Control, as this design is for using the most recent versions of Jabber of Video (NTLM supported).
Enabling Movi/Jabber authentication on the VCS-C and VCS-E using Active Directory Credentials
In a secure design, the VCS (Control and Expressway) would require credentials for registration. Here is a design that is not described in the admin guides, but has been used quite successfully.
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 Active Directory 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 these 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 authenticate 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.
To further expand upon the configuration details above, please note that the account created in Active Directory that used for the SIP Authentication Username needs to reside in the same Windows Domain as the user account used by the client for provisioning. The reason is this:
When the Jabber client user input's their credentials, it will be in the form of DOMAIN\USERNAME. When the Provisioning data is received, only the "USERNAME" field is replaced. When the client auithenticates the registration with the new username, the domain name is not replaced. This could be an issue where the Active Directory domain structure contains multiple child or sub domains, or is a trust relationship is used for authentication.
VCS is joined to parent domain (DOMAIN). The Jabber users reside in child domains (CHILDDOMAIN1 and CHILDDOMAIN2). a user account that has a samaccount name that matches the SIP Authentication Username must reside in both the CHILDDOMAIN1 *AND* CHILDDOMAIN2.
Please keep in mind that this design I come up with would be needed in the scenario I described when using VCS X7.x and X6.x. VCS X8.x offers a new feature of credential delegation. With this feature, it will not be necessary to use the custom design that has been discussed above. The VCS-E can pass the authentication request response for the registration to the VCS-C, even though the registration is taking place at the VCS-E. Once again, I strongly suggest that any of these designs be tested in a lab environment. Also, taking debug diagnostic logs during testing is vital to understanding exactly what is being done in the backend. The VCS diagnostic logs are fairly simple to follow and full of useful information. After taking the time to go through a log or two, the backend end process should be fairly easy to understand and will provide a better avenue for an indepth understand of how the VCS (and all of its configuration options) works.
- Zac Colton
I doubt you will be able to have both AD direct authentication and authentication through local database at the same time as you need to enable NTLM ( auto settings) on VCS for direct authentication to work and new jabber client will use NTLM as preferred method.
The only way i see this working is maybe to have the manual users using an old version of Movi which does not support NTLM so that those usets will be authenticated using the local database. Can't recall from which version NTLM is supported on Movi could be from 4.x
As far as I understand, if AD authentication is enable on VCS, VCS will challenge the client using AD database (NTLM will be necessary) and then the local database (without NTLM). Based upon what you are saying, I can conclude the VCS will never use the local database for authentication, but only AD authentication if it is enable.
Sorry, I may be missing something here, not sure. Can you clarify?
Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
According to some other discussions, when AD service is enabled on VCS, Jabber Video will not longer be able to authenticate using the VCS's local database of users. As AD (NTLM) will be the primary method, which doesn't help when you're using a mix of AD import and manual created accounts in TMS.
Hence, trying to find out how to have the AD imported users authenticate to the VCS Control, and the manually created users to the Expressway. Keeping the authentication methods on separate VCSs allowing for the mix of the two to be used. Since the VCS doesn't do mixed mode authentication, of both NTLM and Digest.
Please see my post regarding the the authentication process. There are basically 2 choices: (1) users without an AD account are limited to Movi 4.1, (2) VCS topology to include VCS that is not an AD member for non-AD Jabber users to use.
Sorry guys. You are right. I missed this point.
I just read VCS authentication guide and that is right. If the client informs support NTLM authentication, VCS will challenge authentication only against AD database.
Thanks Zac for clarify.
Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
Regardless of how users are created inside of the Provisioning database (manually added ort imported), the authentication of the messaging from the client (the SUBSCRIBE for Provisioning or the registration request) is handled completely by the VCS (Control or Expressway). The VCS is not aware of how the accounts were created, and it really doesn't care. Here is a basic rundown of Jabber client authentication.
The VCS has to methods of processing the authentication: NTLM and Digest. If the VCS has Active Directory Services enabled (it has been joined to an Active Directory Domain), when the Client send the subscriibe/registration request and that message hits a zone/subzone confiogured for Check Credentials, the VCS will return a Proxy Authentication Required message back advertizing the NTLM and Digest. The Jabber client will then pick an authentication method. Movi 4.2 or higher will work with NTLM and preferrs it over Digest. The VCS will then process the authentication through NTLM. If the Movi client is older (<4.2) it will only know how to use Digest. The VCS with then authenticate against it's local database.
If the VCS is *not* joined to the AD Domain, it will only advertise Digest authentication, and will only authenticate against it's local database.
There are many things to consider, and you need to keep the big picture in mind. (VCS Control/Expressway topology, Which VCS server have Provisioning data, SIP domain routing - if using multiple domains, Client versions, where thew clients will register).
The only thing I would recommend is to setup a lab deployment and test various designs/configs to see what config matches your requirements. There are many different ways to do what you want. Some may work for you, some may not. The key pieces of information that you need to keep in mind are the details I listed above.
In reference to what you mentioned, sounds like what I described originally.
But can I do that while the AD users and manual users are using the same SIP domain, or do they need to have separate domains? Do I need to take into account any search rules or anything into consideration when using a VCS-C/E with different authentication methods?
A single VCS Control and single Expressway may not work, especially if you want to use a single unified SIP domain.Also, will the AD users only be internal, and will the Manual users only be external?
Manual users will always be external, since they aren't associated with our organization. AD users will be internal and external, so they would at time need to traverse the Expressway to the Control to authenticate. If separate domains is needed, that wouldn't be to bad, just prefer to keep it as simple as possible.
As long as the manual users are only external, what you are trying to do will be possible. It would probably be best to use separate SIP domains, but you can use FindME for a unified SIP domain. Do you have an existing deployment that you can do testing on?
Please, correct if I am missing something here, but I think the following setup would work:
You can use one single VCS control and VCS Expressway, but two SIP domains will be required. I will take as example domain1 (for AD users) and domain2 (for normal users). Also, device authentication can not be enabled, only authentication for provisioning.
- Enable provisioning on VCSe as well as VCSc
- Create sip domain1 and domain2 in Both VCSs
- Change the SIP route patterns in both VCSs to match only the correct domain. The SIP routes that are created when you enable provisioning normally have a pattern with the domain @%localdomains%, which matches all the local sip domains. You can change it to be a specific domain instead of all local domains. So, in VCSc you can change to domain1 and in VCSe domain2.
- Create the proper search rules to route provisioning messages between both VCSs
- enable presence in both VCSs
What do you think?
Sent from Cisco Technical Support iPad App
That is a start but there is more to it. You would also need to take in a ccount a third SIP domain to be used in FindMe so that a unified domain can be used. Some of what you listed is not accurate, but it is close. To find all of the bits and pieces that are needed, I would need to lab this up.
FineMe wouldn't be applied between the two groups. Only the AD users would have FindMe, and even then, the SIP domain for FindMe and the AD group would be the same.
If the VCS-E is set to digest authentication for manual users to login, would the Subscribe/Register end at the Expressway for manual users, however for AD users would it get passed to the Control if the Expressway didn't match the account in it's database, essentially it would keep going down the line until it hit the end and all possible ways to authenticate? If a single domain were to be used.