Currently the organization is using Simble Bind - Active Directory authentication protocol.
Tableau Server 2019.1.3 was installed on a Oracle Linux distribution. The installation process was finished correctly.
Before finishing the installation process, we configured the json file, corresponding to the chosen authenticacion protocol.
The configuration is as follows:
tsm settings import -f ad_auth.json
So far so good, afterwards, we runned the following command:
tabcmd initialuser --server 'localhost:80' --username 'ad_user' --password 'secret_password'
As before, all good. Just to clarify, ad_user ins't the tsm user which was used during installation, is just the user that TS needs to communicate with the AD Server.
After completing the installation and using the TS for about one onth with no issues, the Security Department decided to change the "ad_user" user (the initial user, which is the administrative user and also an Active Directory user) password for security reasons, and that's when we started to experience the following issues:
- Can't logon to the TS web as "ad_user" user. The login screen stated "Wrong user or password".
- None of the previously imported users from the AD coul'd logon to the TS web. Wrong credentials as well.
After searching in the /var/.../vizportal/vizportal_node1-0.log (where authenticacion logs are), I've found this fragment:
2019-08-02 08:19:08.204 -0400 (-,-,-,XUQqPH@eq@wAOzTQm6HIfQAAAF0,0:-5a1cdfd2:16c51e8c8fd:-3b86) catalina-exec-2 vizportal: ERROR com.tableausoftware.ldap.LdapSearchService - Sign in for user failed: com.tableausoftware.domain.ldap.LdapConnectException: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580 ] (errorCode=100049)
2019-08-02 08:19:08.204 -0400 (-,-,-,XUQqPH@eq@wAOzTQm6HIfQAAAF0,0:-5a1cdfd2:16c51e8c8fd:-3b86) catalina-exec-2 vizportal: INFO com.tableausoftware.domain.user.ADIdentityProvider - AD sign in attempt for: firstname.lastname@example.org failed
From the LDAPWIKI docs I've found that - ERROR_LOGON_FAILURE
I've tried the "tsm reset" command but this command fails because "ad_user" isn't the tsm user. Tried to re-import a new ad_auth.json file with the new password but, the values can't be changed for this is a "hard coded" and "encrypted" configuration. If I need to change something, the TS needs to be reinstalled. We can't reinstall everytime we need a password to be changed. We tested it Windows side, and the "ad_user" user logs on successfully with the new password, but no sucess TS side.
So, to give the users full access again, we rolled it back to the previous password and all worked it again. This strongly states to me that the initial user password is hardcoded.
Three critical question arise after this issue,
- First, can the password, of initial AD user, be changed in the AD source, expecting for the TS to assume it authomatically ? Given the logic of the AD authenticacion, TS does not perform any task (as the official TS documentation says), is up to the AD service on Windows. So, we could change any attribute of our AD users, like passwords, on the AD source and TS should sync it normally.
- And second, does the "ad_user" has to, necessarily, be a TS licenced user as well ? I'm talking about being the initialuser.
- A tsm parameter exists for this kind of changes (username, mail, profile pic, etc) and is the vizportal.adsync.update_system_user parameter, which, is false by default. I've made the changes to true and configure the Active Directory Groups Sync server side after the roll back, but, how can I assure the Security Department that, if we now change the initial user password, this parameter would update the password TS side ?. They'll need to change this password each week due to internal policies and it's critical, because the TS will be publish (to access it outside the company) by the end of the year. We need to protect the administrative user password in case of change the company personel and prevent information leaks.
I've opened a support ticket but no answer to this time (Case numb. 05182007)