search cancel

NullPointerException when attempting to logon to the Streaming Console when UDS configured for ADSI


Article ID: 161600


Updated On:


Workspace Streaming (formerly AppStream)


Network users may not be able to login to the Streaming Console and may receive a false message indicating their username or password was entered incorrectly when in fact no error has been made inputting the user's credentials when the User Data Source (UDS) is configured to use the Active Directory Services Interface (ADSI) instead of the legacy LDAP connector; ADSI is the default setting for new installations, upgrades will use the existing LDAP connector.

Streaming Console login error

In addition to the error message depicted above, you can enabling debug logging on the Streamlet Engine by editing the ste.conf file located at C:\Symantec\Workspace Streaming\Server\streamletEngine\conf and changing the parameter and setting its value to DEBUG. The following message is recorded in DCI_all.log when dbimpl debug logging is enabled:

2014-10-09 15:36:20,252 DEBUG [http--] authenticateConsoleUser| [USER_SERVICE] authenticateUser username: username
2014-10-09 15:36:20,283 DEBUG [http--] authenticateConsoleUser| [USER_SERVICE] AdsiUserManagement.searchUsers count 1
2014-10-09 15:36:21,299 DEBUG [http--] authenticateConsoleUser| [USER_SERVICE] DBUserManagement getUser name [email protected]
2014-10-09 15:36:21,315 ERROR [http--] authenticateConsoleUser| java.lang.NullPointerException
2014-10-09 15:36:21,315 DEBUG [http--] authenticateConsoleUser|
at org.apache.torque.util.SqlExpression.processInValue(
at org.apache.torque.util.SqlExpression.buildIn(
at org.apache.torque.util.Criteria$Criterion.appendTo(
at org.apache.torque.util.Criteria$Criterion.toString(
at org.apache.torque.util.BasePeer$3.process(
at org.apache.torque.util.SQLBuilder.processCriterions(
at org.apache.torque.util.SQLBuilder.buildQueryClause(
at org.apache.torque.util.BasePeer.createQuery(
at org.apache.torque.util.BasePeer.doSelect(
at com.appstream.dbimpl.DAImpl.retrieveConsoleUser(
at com.appstream.dbimpl.DAImpl.authenticateConsoleUser(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at com.appstream.db.util.ClassUtilities.invoke(
at com.appstream.db.remote.DbMsg.invoke(
at com.appstream.dbimpl.DAMgr.handleMsg(
at com.appstream.db.remote.AbstractManager.doService(
at com.appstream.db.remote.DAServlet.doPost(
at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.valves.ErrorReportValve.invoke(
at org.apache.catalina.core.StandardEngineValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.service(
at org.apache.coyote.http11.Http11Processor.process(
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(


The service account configured in the UDS that is used to access the directory service may not have sufficient privileges to read a group in the user's group membership list; this resulted in a searchGroupsInt call returning an empty array. The calling Java function didn't expect this as it constructed its SQL statement. We now return a NULL in ADSI's java_com_appstream_dbimpl_usermgmt_AdsiUserManagement_searchGroupsInt and the user can now login.


This defect is targeted to be fixed in 7.5 SP1 HF3; upgrading to this version will resolve the problem.  

There are a couple of workarounds in the meantime:

  1. Change the UDS configuration to use the legacy LDAP configuration instead of the ADSI connector
  2. Contact Symantec Technical Support to obtain a point fix for this issue


Workaround 1

  1. Make a backup copy of the following file:
    1. C:\Symantec\Workspace Streaming\Server\streamletEngine\da\conf\provision.xml
  2. Replace the content of the original provision.xml with the data from the following file:
    1. C:\Symantec\Workspace Streaming\Server\streamletEngine\da\conf\provision_LDAP.xml
  3. Login to the Streaming Console
  4. Navigate to the UDS configuration screen
    1. Settings > System Settings > User Data Source
    2. Fill in the missing values as appropriate to connect to your directory service


Workaround 2

  1. Reproduce the problem to verify which users cannot login
  2. Stop the SWS Streamlet Engine (ASWEStreamletEngine) service
  3. Make a backup copy of the original awe_legacy.jar file and store it in a separate directory, e.g., c:\temp
    1. C:\Symantec\Workspace Streaming\Server\common\jboss\modules\appstream\lib\main\awe_legacy.jar
  4. Replace the awe_legacy.jar file in the location above with the attached awe_legacy.jar file
  5. Start the SWS Streamlet Engine (ASWEStreamletEngine) service
  6. Test the logon of the accounts that previously failed in step 1


Applies To

Symantec Workspace Streaming (SWS) (GA) through SWS (SP1 HF2) with the User Data Source (UDS) configured to use Active Directory Services Interface (ADSI).


awe_legacy.jar get_app