This explains How Jabber Client(JC) Login works, Types of JC login and how to troubleshoot JC login issues.
Jabber Client Login and Login Issues
-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.
>>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)
>>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.
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)
The above service profile selected in the end user page, as above 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.
++ 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
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.
++ 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
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
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:
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'
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>
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.
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@b492e9
2011-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@b492e9
2011-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@b492e9
2011-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@b492e9
2011-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@b492e9
2011-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
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
