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

Discussion created by Michael_Lowry on Nov 21, 2017
Latest reply on Feb 6, 2018 by JohnO'Mullane

Like • Show 0 Likes0
Comment • 5

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:

https://awi.mycompany.com/#&system=AWI_SYS1&client=0001&sso=yes&autologin=yes

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(Connection.java:1614) at com.uc4.communication.Connection.login(Connection.java:1585) at com.uc4.webui.api.connection.AEConnectionAdapter.login(AEConnectionAdapter.java:74) at com.uc4.ecc.backends.impl.dataservice.connection.ConnectionService.login(ConnectionService.java:220) at com.uc4.ecc.backends.dataservice.connection.IConnectionService$pbryglu.login(Unknown Source) at com.uc4.ecc.backends.impl.dataservice.login.Authorization$Login.login(Authorization.java:67) at com.uc4.ecc.backends.impl.dataservice.login.LoginService.login(LoginService.java:26) at com.uc4.ecc.backends.dataservice.login.ILoginService$pbryglu.login(Unknown Source) at com.uc4.ecc.framework.entrypoint.login.ae.AECredentialsPresenter.performAutomationEngineLogin(AECredentialsPresenter.java:265) at com.uc4.ecc.framework.entrypoint.login.ae.AECredentialsPresenter.login(AECredentialsPresenter.java:194) at com.uc4.ecc.framework.entrypoint.login.ae.AECredentialsPresenter.access$200(AECredentialsPresenter.java:43) at com.uc4.ecc.framework.entrypoint.login.ae.AECredentialsPresenter$2.load(AECredentialsPresenter.java:162) at com.uc4.ecc.framework.entrypoint.login.ae.AECredentialsPresenter$2.load(AECredentialsPresenter.java:155) at com.uc4.ecc.framework.core.async.BaseRequestCoordinator$1$1.call(BaseRequestCoordinator.java:223) at com.uc4.ecc.framework.core.pool.ContextAwareExecutorService$CallableImplementation.call(ContextAwareExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) 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 [trypoint.login.ae.AECredentialsPresenter] - 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.

[uc4.webui.common.properties.Configurable] - Loaded configuration value: sso.enabled -> false (false default)

Once I re-enabled SSO in configuration.properties 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.”

Outcomes

JohnO'Mullane Feb 5, 2018 10:46 AM

Michael_Lowry
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?
John.

Actions

JohnO'Mullane Feb 6, 2018 12:29 PM

Michael_Lowry
Thanks for that, really helpful.
Do you think the Official Documentation has been updated with your findings?

Actions

Michael_Lowry Feb 6, 2018 2:25 PM

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.

Actions

JohnO'Mullane Feb 6, 2018 2:10 PM

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.

Actions

5 Replies

JohnO'Mullane Feb 5, 2018 10:46 AM
Michael_Lowry
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?
John.
Like • Show 0 Likes0
Actions
Michael_Lowry Feb 5, 2018 1:01 PM
JohnO'Mullane: I suggest you read my other SSO-related threads:
Like • Show 1 Like1
Actions
JohnO'Mullane Feb 6, 2018 12:29 PM
Michael_Lowry
Thanks for that, really helpful.
Do you think the Official Documentation has been updated with your findings?
Like • Show 0 Likes0
Actions
Michael_Lowry Feb 6, 2018 2:25 PM
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.
Like • Show 1 Like1
Actions
JohnO'Mullane Feb 6, 2018 2:10 PM
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.
Like • Show 1 Like1
Actions

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

Outcomes

Related Content

Recommended Content