Jabber Client Login

Two Types:

Automatic Login

Manual Login

Flow that the Jabber client uses to connect to services:

In this doc we are not discussing WebEx Messenger service.

Note: Expressway also called collab-edge (one of type of login request from jabber client) which you would see in coming slides.

Jabber Client Login and Login Issues

>>Automatic Login: Here you just need to enter the userid@domainname , when you click on Continue, below requests are sent from Jabber client to DNS SRV(service Record).

First always Jabber client sends:

SRV_cisco-uds._tcp.example.com (example.com is domain name like cisco.com,ccie.com, changes from company to company what they have configured) to get the CUCM IP address. If DNS query fails (i.e in DNS SRV there was record for this service type), then Jabber client sends below.

SRV_cuplogin._tcp.example.com------> To get CUPS (presence server) IP.

If this fails, then below is sent.

SRV_collab-edge._tls.example.com------>Jabber client thinks that it is outside company network on WAN, so through internet it contacts VCS servers to contact Presence Servers.

>>If any one of the above succeeds (Jabber client sends http request to CUCM/CUPS IP), if the userid exists in CUCM/CUSP, then password would be prompted

If all fails, then we need to go for Manual Login (explained in coming slides)

Automatic Login

Enter your user-id(ex: john1@ccie.com) and click continue.

SRV (Service record)

- It’s specification of data in the DNS server defining the location i.e., hostname and port number of servers for specified services.

- Transport protocol involves TCP or UDP.

>>Basically, in DNS SRV you define here for every “service type” of DNS query a resolution.

>>>Above shows, that a service record added for service _cisco-uds in DNS.

So here, when Jabber client request for SRV_cisco-uds._tcp.ccie.com, the DNS SRV sends the CUCM IP to Jabber client.

Also it sends the port number through which the Jabber needs to contact the CUCM Server.

Priority: If you are defining multiple CUCM IP, you can give priorities to each IP’s, based on priorities Jabber client contact those IP.

Weight: You mention values here, if you mentioned same priorities for CUCM IP’s. Inside same priorities CUCM IP’s, one with more weight would be preferred.

Once Jabber gets, the IP address, it sends http request to CUCM IP along with the port number.

>>Similarly we add here for service “_cuplogin” for CUPS IP.

DNS SRV

For Manual Login, click on Advanced Settings:

-Automatic which is explained in previous slide (When Jabber starts initially for the first time after installation this is checked by default)

-Cisco IM & Presence: when this is clicked you can select “user the default server (in this case jabber always sends SRV_cuplogin._tcp.example.com request to DNS SRV) or you can select “user the following server” with CUPS server IP(so jabber client contacts CUPS server)

-WebEx Messenger: this is something managed Cisco cloud WebEx service, not discussed here.

- Cisco CM 8.x or 9.x (or later): when this is clicked you can select “user the default server(in this case jabber always sends SRV_cisco-uds._tcp.example.com request to DNS SRV) or you can select “user the following server” with CUCM server IP (so jabber client contacts CUCM server)

• When CUCM 8.x is chosen in above side, the Jabber client (JC) just acts as a normal SIP phone (in 8.x there is no service profile option in end user page, so JC will not get details about its CUPS). JC will act as a deskphone mode with no chat options.

• When 9.x is selected, JC gets CUPS details and it can be used for calling and chat purpose.

Manual Login

• When a request is received from Jabber to CUCM, how jabber comes to know where is its presence server/VM server/directory search options etc.

• In CUCM end user page, you configure as below. The UC service profile (show in next slide shows diff options.

The above service profile selected in the end user page, as below configs:

VM profile: VM options for jabber client

Directory profile: Jabber client contact this when there is contacts search in jabber client.

IM and presence Profile: contains Presence (CUPS) details.

Config in CUCM

• CUCM tomcat service checks in LDAP/Active directory if this user exists in its database and if presents its authenticated successfully.

• Now the JC gets the presence server (CUPS) details from service profile and contacts presence server.(Now again CUPS tomcat service authenticates this user through LDAP. Even though CUSP and CUCM are in same cluster higher versions, they maintain their own authentication)

++ Below shows Tomcat security logs from CUCM, how CUCM checks in LDAP and authenticates this user.

We can track this request from JC in logs with number 47(which is same for this user login process) and number keeps changing for other user login request.

2014-11-05 11:59:07,716 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - authenticateUserWithPassword: userName=nirmal2014-11-05 11:59:07,716 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - SearchUserDn for nirmal

2014-11-05 11:59:07,908 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - makeConnection: ldapURL[0]=ldap://10.106.89.210:389

2014-11-05 11:59:07,916 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - searchUserDn: performing search with userBase=CN=users, DC=ccie, DC=com, filter=(&(&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))(sAMAccountName=nirmal)), constraints=javax.naming.directory.SearchControls@c201cb

2014-11-05 11:59:07,921 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - authenticateUserWithPassword: calling auth as dn search is successful for user nirmal and the dn is CN=Nirmal Issac, CN=users, DC=ccie, DC=com

2014-11-05 11:59:07,938 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - auth: successful for dn CN=Nirmal Issac, CN=users, DC=ccie, DC=com

What happens When Jabber client(JC) contacts CUCM

Events which occur, when JC contacts CUPS:

++ JC sends a SOAP Login request to CUPS. Client Profile Agent service on CUPS (which talks on SOAP) does two things here.

1) With the help of Tomcat security service on CUPS, it authenticates this user against Active directory (similarly as in CUCM) and gets this user info table, if this user exists in the database.

2) If the user exists, it does XMPP authentication, which checks whether this user as presence feature enabled (right to contact presence server), license etc.

Note: All these users are added in end user page in CUCM and synced through LDAP.

CUPC: Cisco Unified Presence Client (Jabber client, Android and other Devices

Client Profile Agent: A service in CUPS which talks on SOAP.

What happens When Jabber client(JC) contacts CUPS

++ Once both the authentication is, as explained in previous slide note, the Client profile agent sends login response to JC as above and JC gets the config file(JC gets service profile config etc, similar to what we see in CUCM)

Below is the example of outputs from Client Profile Agent service logs from CUPS:

- Incoming SOAP request from JC to CUPS.

2014-11-12 10:26:43,969 DEBUG [http-bio-443-exec-23] soap.SoapServlet - Incoming Request<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns1="urn:cisco:epas:soap"><SOAP-ENV:Body><ns1:login client-version="9.7.5.19280" client-type="CUPC" force="true"><ns1:username>nirmal</ns1:username><ns1:password>...</ns1:password></ns1:login></SOAP-ENV:Body></SOAP-ENV:Envelope>

- Client profile checks this user agianst Active directory and authenticates this user with the help of tomcat security service in CUPS.

2014-11-12 10:26:44,155 INFO [http-bio-443-exec-23] handlers.LoginHandlerNonSSO - doLogin:IMS login result is success for nirmal| IMS result code:0

XMPP authentication

2014-11-12 10:26:44,159 DEBUG [http-bio-443-exec-23] imdb.ImdbLoginAccessorUtil - Insert session succeeded for userid:nirmal

2014-11-12 10:26:44,159 INFO [http-bio-443-exec-23] handlers.LoginHandlerAbstract - SOAP Login was successful

2014-11-12 10:26:44,159 INFO [http-bio-443-exec-23] handlers.LoginHandlerAbstract - doLogin:IMDB check completed & session created for user:nirmal. SessionKey is: cfd514ad-49e5-2e97-6a2c-64cdfda98cc8

2014-11-12 10:26:44,161 INFO [http-bio-443-exec-23] soap.SoapServlet - SOAP request URI: /EPASSoap/service/v802014-11-12 10:26:44,162 DEBUG [http-bio-443-exec-23] soap.SoapServlet - Service version requested: v80

- Once the SOAP authentication is successful, the JC sends Token request(which acts as One Time password) to Client Profile Agent in CUPS.

- Client Profile Agent responds back to JC with Token.

Through this Token JC starts conversation with other services in CUPS(XCP services).(Just like token based authentication)

Example from Client Profile Agent Service logs :

2014-11-12 10:26:44,278 DEBUG [http-bio-443-exec-23] ext.SoapRequestParserExt - Parsing SOAP request securely with a SecurityManager set

2014-11-12 10:26:44,279 INFO [http-bio-443-exec-23] soap.SoapServlet - SOAP request for: get-onetime-password, version: v80

2014-11-12 10:26:44,285 INFO [http-bio-443-exec-23] handlers.GetOneTimePasswordHandler - GetOneTimePasswordHandler: successful

2014-11-12 10:26:44,285 INFO [http-bio-443-exec-23] handlers.GetOneTimePasswordHandler - GetOneTimePasswordHandler: Returning response for get-onetime-password

• JC contacts XCP Connection Manager with this token, to talk to XCP services.

• CUPS as two database (one for Presence clients and other for CUCM), since Client logins needs to be more secured (to prevent hacking into system) the “XCP connection Manager” asks “XCP Authentication Service” to authenticate this Token before the JC can start communication with XCP services.

• Once “XCP Authentication Service” confirms that this is a valid Token, JC can start communication with XCP router(all XMPP communications)

• Example Logs:

• Connection Manager Logs: XCP connection Manager service receives Token from JC.

• 10:26:46.981 |076a1b70| debug| SASLManager.cpp:426 SASLManager::stepSession sending: <auth mechanism='CISCO-VTG-TOKEN' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>dXNlcmlkPW5pcm1hbEBjY2llLmNvbQB0b2tlbj05MTEyMTU=</auth>10:26:46.987 |07ce6b70| debug| SASLManager.cpp:259 xdbSessionCB: id=jtx_56

• XCP Authentication Service Logs:

• - XCP Authentication Service receives msg from XCP Connection manager to verify the Token.

• 10:26:46.982 |00000000| debug| auth-1.10-106-89-222 AuthXCPComponent::onPacket()

• 10:26:46.982 |00000000| debug| AuthXCPComponent.cpp:211 AuthXCPComponent::onPacket(): <xdb from='cm-1_jsmcp-1.10-106-89-222' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='ccie.com' type='set'><auth mechanism='CISCO-VTG-TOKEN'

• -Token Verification is successful

• 10:26:46.986 | debug| SXComponent::authenticateVTGToken(): Authentication success for userid: [nirmal@ccie.com]

• 10:26:46.986 | debug| SXComponent::_sendAuthSuccess(): JID: [nirmal@ccie.com]

• 10:26:46.986 | debug| SXComponent::_sendAuthSuccess(): [PACKET_OUT]: <xdb from='ccie.com' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='cm-1_jsmcp-1.10-106-89-222' type='result'><success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/><x><field var='FORM_TYPE'><value>http://www.jabber.com/schemas/saslprops.xsd</value></field><field type='text-single' var='sasl-service'><value>ccie.com</value></field><field type='text-single' var='sasl-mechname'><value>CISCO-VTG-TOKEN</value></field><field type='text-single'

XCP Authentication Service Logs:

- XCP Authentication Service receives msg from XCP Connection manager to verify the Token.

10:26:46.982 |00000000| debug| auth-1.10-106-89-222 AuthXCPComponent::onPacket()

10:26:46.982 |00000000| debug| AuthXCPComponent.cpp:211 AuthXCPComponent::onPacket(): <xdb from='cm-1_jsmcp-1.10-106-89-222' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='ccie.com' type='set'><auth mechanism='CISCO-VTG-TOKEN'

-Token Verification is successfully done by XCP Authentication Service.

10:26:46.986 | debug| SXComponent::authenticateVTGToken(): Authentication success for userid: [nirmal@ccie.com]

10:26:46.986 | debug| SXComponent::_sendAuthSuccess(): JID: [nirmal@ccie.com]

10:26:46.986 | debug| SXComponent::_sendAuthSuccess(): [PACKET_OUT]: <xdb from='ccie.com' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='cm-1_jsmcp-1.10-106-89-222' type='result'><success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/><x><field var='FORM_TYPE'><value>http://www.jabber.com/schemas/saslprops.xsd</value></field><field type='text-single' var='sasl-service'><value>ccie.com</value></field><field type='text-single' var='sasl-mechname'><value>CISCO-VTG-TOKEN</value></field><field type='text-single'

• Once Token verification is done, the “XCP Connection Manager” opens the channel to XCP router service and the JC will start communications with XCP router service.

• XCP Router Service in CUPS: used for all XMPP communications(just like ccm service in CUCM)

• Presence Engine Service in CUPS: Used for status of users.

XCP connection Manager Informs JC about Token Authentication Successful.

10:26:46.987 |076a1b70| debug| SASLManager.cpp:272 _xdbSessionCB: <xdb from='ccie.com' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='cm-1_jsmcp-1.10-106-89-222' type='result'><success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/><x><field var='FORM_TYPE'><value>http://www.jabber.com/schemas/saslprops.xsd</value></field><field type='text-single' var='sasl-service'><value>ccie.com</value></field><field type='text-single' var='sasl-mechname'><value>CISCO-VTG-TOKEN</value></field><field type='text-single' var='JID'><value>nirmal@ccie.com</value></field></x></xdb>

From XCP Router Service Logs:

- Connection Manager Initiates communication with the XCP Router Service

10:26:46.982 |f743bb70| debug| MIOByteSource.cpp:96 Got Buffer (249) <xdb from='cm-1_jsmcp-1.10-106-89-222' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='ccie.com' type='set'><auth mechanism='CISCO-VTG-TOKEN' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>dXNlcmlkPW5pcm1hbEBjY2llLmNvbQB0b2tlbj05MTEyMTU=</auth></xdb>

• Since now we seen how Jabber login works and how working logs looks like, below are the logs which needs to be collected for Jabber Login Issues:

• From CUPS: (from RTMT)

‘Client Profile Agent’ service

‘XCP Connection Manager’ service.

‘XCP Authentication Manager’ service

‘XCP Router’ service

• From CUCM:

Tomcat security logs.

NOTE: CUP server contacts the LDAP server to authenticate the user who logs-in into the client by providing username/password. Client Profile Agent logs (commonly called epassoap logs) will show some 'Reason Codes' that indicate why the authenticaiton failure occurred. These are seen when LDAP is used to synchronize and also authenticate the end users in the UC environment. So the 'Action' item defined here has to be done on the AD server. Note that these codes are specific to only LDAP authentication step of overall login sequence and are helpful to conclude if the issue is with LDAP to start with.

• Suuccessfull Login:

• 2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e9

• 2011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :0

• The next step is to continue looking into epassoap(client profile agent service) logs to investigate further.

• In the added notes below are few login issues related logs.

• Also, you can click on File—create problem report in jabber client for login issues just to get an overview idea, but to get full idea about what’s the issue is we need to collect logs from Presence server.

Logs to Collect

Login Failures

Account related

1) Wrong credentials

2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e92011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :1

Action: Collect $TOMCAT_HOME/logs/security/log4j/security*.log

2) Account hack locked

2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e92011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :3

Action: Reset user account

3) Admin has locked account

2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e92011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :2

Action: Reset user account

4) Account locked due to inactivity

2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e92011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :4

Action: Reset user account

5) Account LDAP inactive

2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e92011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler -IMS result code is :5

Action: Reprovision user on LDAP & res-sync from LDAP

• Few more Jabber login issue below in notes.

• Many login issues occur due to improper or wrong entries in the DNS SRV lookup. Make sure from your PC cmd prompt, DNS SRV is working fine.

• Below example is for testing DNS SRV lookup from cmd prompt. Type nslookup and hit enter and proceed with below test.

• When you do DNS SRV lookup for _cisco-uds service, we can see below that we get the CUCM info.

jabber login error code 14

Problem

Jabber Client received “Cannot communicate with the server” when login into Jabber for windows

Solution

In jabber problem report we have seen the error code 14 when login.

[JabberWerx] [IMPStackCap::Log::log] - [JabberWerxCPP.DLL]: JWLoginSink::OnError, lerr:14

For Error code 14, it is due ot the cups server is not defined using fqdn or ip address client cups server under system->cluster topology, it is not using fqdn nor ipaddress

After changed server to ip address, then client is able to log

Few links: http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/jabber-windows/116334-trouble-jabber-problem-00.html

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide.html