Automic Workload Automation

Expand all | Collapse all

NPE from AWI if SSO URL is used but SSO is disabled

  • 1.  NPE from AWI if SSO URL is used but SSO is disabled

    Posted 11-21-2017 10:04 AM
    This morning I tried to log in to our v12.1 system using a parameterized URL. The URL’s paramters included sso-yes and autologon=yes, instructing the AWI to try to log in immediately using single sign-on:
    The AWI login screen appeared but it immediately displayed a null pointer exception.

    The AWI log provided a bit more information about the NPE:
    2017-11-21 14:26:52,126 pool-2-thread-1        [WARN ] NOSESSION/- NOUI  +1 [dataservice.connection.ConnectionService] - Login to UC4 Automation Engine failed.
    java.lang.NullPointerException: null
         at com.uc4.communication.Connection.login(
         at com.uc4.communication.Connection.login(
         at com.uc4.webui.api.connection.AEConnectionAdapter.login(
         at com.uc4.ecc.backends.impl.dataservice.connection.ConnectionService.login(
         at com.uc4.ecc.backends.dataservice.connection.IConnectionService$pbryglu.login(Unknown Source)
         at com.uc4.ecc.backends.impl.dataservice.login.Authorization$Login.login(
         at com.uc4.ecc.backends.impl.dataservice.login.LoginService.login(
         at com.uc4.ecc.backends.dataservice.login.ILoginService$pbryglu.login(Unknown Source)
         at com.uc4.ecc.framework.core.async.BaseRequestCoordinator$1$
         at com.uc4.ecc.framework.core.pool.ContextAwareExecutorService$
         at java.util.concurrent.ThreadPoolExecutor.runWorker(
         at java.util.concurrent.ThreadPoolExecutor$
    2017-11-21 14:26:52,126 pool-2-thread-1        [TRACE] NOSESSION/- NOUI  +1 [dataservice.connection.ConnectionService] - Closed connection com.uc4.webui.api.connection.AEConnectionAdapter@68b08d3f
    2017-11-21 14:26:52,130 pool-2-thread-1        [DEBUG] NOSESSION/- NOUI  +1 [] - Failed login
    The log did not clearly point to the cause of the problem, and it took me a while to figure it out. I had disabled SSO for testing, and had forgotten to re-enable it.
    [] - Loaded configuration value: sso.enabled -> false (false default)
    Once I re-enabled SSO in and restarted the AWI, the problem went away. It would be nice if the AWI displayed a more descriptive error message in this situation — e.g., “Single sign-on is disabled.”

  • 2.  NPE from AWI if SSO URL is used but SSO is disabled

    Posted 02-05-2018 05:47 AM
    Hi Michael, I'm currently upgrading to 12.1.1 from 12.0. 
    I wasn't aware of SSO until now.
    Is there much work in getting SSO setup?

  • 3.  NPE from AWI if SSO URL is used but SSO is disabled

  • 4.  NPE from AWI if SSO URL is used but SSO is disabled

    Posted 02-06-2018 07:29 AM
    Thanks for that, really helpful.
    Do you think the Official Documentation has been updated with your findings?

  • 5.  NPE from AWI if SSO URL is used but SSO is disabled

    Posted 02-06-2018 08:05 AM
    Automic have definitely improved the documentation, but I would not say it’s complete.

    Setting up SSO for the Java User Interface is a bit of a hassle, particularly if you run the AE on multiple hosts. When we discovered how much trouble it was to get SSO working with the JUI, we decided that we would wait to enable SSO until we had migrated to the AWI. The JUI is being deprecated anyway, for better and worse.

    Automic’s documentation appears to have been written from the point of view of someone who is setting up a test system in an Active Directory domain on which he/she has full administrative privileges. To wit, the documentation assumes that the person creating the keytab will be the same person as the person creating the SPN in the KDC. Many enterprise IT environments are not like this. At least in our environment, there is a clear separation of roles. I am able to run ktpass to create a keytab, but am not authorized to use the /mapuser parameter to make changes in Active Directory. An AD administrator must do that.

    Because of this separation of roles, it was a real challenge to make sure that the encrypted password in the keytab matched the password in the KDC. Why? Because the encrypted password that the KDC expects depends not only on the service user’s password, but also on the salt, a value that is based on the Kerberos realm and the UPN at the time the SPN was mapped to a UPN. At least in Active Directory’s KDC, there is a one-to-one relationship between SPNs and UPNs.

    When you generate the keytab using ktpass, you must specify the correct salt using the /rawsalt parameter. Microsoft does not fully document how the salt is set, and I found no straightforward way of reading it out from the KDC. The only 100% reliable way I found to determine the correct salt is to run a packet trace of a kinit. I used WireShark to capture a packet trace while I ran kinit as the service user. In the trace I was able to see the salt I needed to use when running ktpass.

    Automic should expand the documentation to describe this process. Better yet, Automic should document a reliable way of finding the salt that does not require running a packet trace. Automic should probably also expand the documentation to include instructions for non-Microsoft KDCs.

  • 6.  NPE from AWI if SSO URL is used but SSO is disabled

    Posted 02-06-2018 09:11 AM
    Thanks Michael_Lowry
    We are AWI only but have 3 hosts(SYSTEMS), for our 3 instances, DEV, UAT and PROD.
    Will give it a go and see how we get on.