Friday, October 16, 2015

OnBase isn't.



Executive summary:  OnBase has terrible technical support, and the simplest things are either not supported or are not possible. (oh, but I found out they have a slide)


I had a ticket to push out using Group Policy a change to the ODBC settings for OnBase users, as the back-end database server was being moved and upgraded.  Simple right?

This:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\OnBaseProd]
"Driver"="C:\\Windows\\SysWOW64\\sqlncli10.dll"
"Description"="OnBaseProd"
"Server"="serverA.company.blah "
"Database"="OnBase"


Is replaced through group policy to:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\OnBaseProd]
"Driver"="C:\\Windows\\SysWOW64\\sqlncli10.dll"
"Description"="OnBaseProd"
"Server"="serverB.company.blah "
"Database"="OnBase"


Seems pretty straightforward.  Notice that only one line was changed, and it was the server name.  (This was also done for the 32bit side too, after discovering that OnBase can ONLY use the 32bit drivers.)

(Disclaimer:  I was not around for the initial installation of the OnBase, I am not the OnBase admin, I am not the OnBase DBA.  I am a Server Admin who takes care of Active Directory, GPOs, and lots of other non-OnBase items.  My views do not necessarily reflect those of my employer...)

A few hours later, users get the GPO, and OnBase doesn't work.  They keep getting prompted for a username.  We tested this numerous times for months, this hasn't happened in our test environment.

We look around the new DB server, all security settings, users, and roles are the same.  It appears that OnBase security is based upon (at least at the DB connection level) the hostname of the connecting client.  No prob we thought, as you can read above, has not changed.  We added the AD user group to the same role as the machines... nothing.

After fusing around a bit, we decide to call OnBase Tech support.  I was surprised by the lack of support... and I have worked with Adobe tech support.

Me:  We changed ODBC server name, clients are prompted to log in... but it doesn't work, did we miss something?
OnBase:  You have to log in with the user HSI.
Me:  But the DB user HSI is a database owner.
OnBase:  Yeah.

<a few min later as I clarify with him>
Me:  So you want me to figure out how to push a database owner username and clear text password to 5,000 machines?
OnBase:  Yes, that is the only way to make the initial connection to the DB for the Thick Clients.
<I put the phone on mute while my partner talks to the Tech support guy and I bang my head against the wall>
<Also, to get an idea of the type of security OnBase uses, their "network security" password that is hard coded into the server app is "ROMANZO" as documented.>

Me:  So what about if we create a new user in the DB, one that is not the DB owner (and therefore cannot delete all the tables in the database, give that user permissions to only edit the necessary tables that are needed for the initial setup?
OnBase:  That won't work, as the OnBase Thick client is hard coded to only accept the username HSI.  You have to use that username or it wont work.
<I think to myself, are you effin' kidding me?>

Me:  Ok, what about if I remove most of the permissions for HSI, so it is not an owner of the DB (And capable of destroying years of work), so that HSI is only used for the initial install for clients?
OnBase:  Changing any of the Database backend will violate our contract with you and we will not support you anymore.

<I am not sure how we can get any less support at this point in time... time to frame it a different way, perhaps it is a communication problem... as sprinkled throughout this conversation, he kept saying it is a Microsoft ODBC problem>
Me:  Ok, let's say I am a multinational corporation, and I want to install your product remotely to thousands of clients across the world.... how would I do that?
OnBase:  We don't support installation of our clients.
<this was then confirmed by our OnBase sysadmin who said they had to write a custom installer to copy files, write registry keys, create shortcuts, etc..... I couldn't believe it.>

After trying a few more perspectives, I realized that every machine was going to have to be touched by a person who is trustworthy enough to know the password to the database owner user.

So like everyone else who is out of ideas, I decided to take to Twitter:



Hey, I recieved a message from "+OnBase by Hyland " asking me to direct message them, so I do.


I wrote them back:  (Times are approx and local, timespans are not)


Bryan
Hello,  Could we talk via phone, my number is xxx-xxx-xxxx.... have a meeting in about 30 min or so, then back after 1:30ish
(10:20AM Thurs)

 OnBase by Hyland 
 Bryan, (Name of person who if find out is our sales rep) will be reaching out to you shortly. Thank you.
(11:20AM Thurs)

 Bryan
 great, it is 2:00 XX time as I write this
(2:00PM Thurs)

 Bryan
 or, you can e-mail me at mywork.e-mailaddresshere to schedule some time or start an e-mail thread
(2:00PM Thurs)

 OnBase by Hyland
 Sounds good! We will be in touch soon.
(2:00PM Thurs)

 Bryan
 I am leaving, as I have been here since 6am or so.... I am here normally 8:-4:30ish AZ time
(4:40PM Thurs)

 OnBase by Hyland 
 (Name of person who if find out is our sales rep) has been in touch with your Sys Admin to resolve any issues. Thanks for reaching out!
(5:30AM Fri)

 Bryan
 I am the server admin.  Was there a solution other than handing out the HSI username and password to every user?
(6:30AM Fri)

 OnBase by Hyland 
 Let us look into this and get back to you. Thanks!
(6:30AM Fri)



So here is a multi-million dollar software company who has technical support reps who told us "we were not trained on that, " or "I don't see anything in the manual about that," requires normal users to log in using the database owner account, and doesn't have a way to deploy their  "thick clients" using the number one business software in the world (Microsoft Active Directory)?

Hey, but at least they have a corporate slide I guess:
https://en.wikipedia.org/wiki/Hyland_Software#/media/File:Hyland_redslide.jpg


--Bryan


6 comments:

  1. Wow, I appreciate you putting this out there. I am in exactly the same situation. I can't even get the call back. All I really need is the default password for the sql user 'hsi' ? It wasn't ROMANZO. Can't find in documentation either. Thanks in advance.

    ReplyDelete
  2. Trying again. What is the sql user password for 'hsi' ? I am in the same position, can't get a call back. Can't find in docs. I appreciate you writing this up. Chris.kathman@gmail.com

    ReplyDelete
  3. If everything was configured correctly you shouldn't have had any issues and your users shouldn't have received prompts. This type of issue is very quick and easy to fix as long as you're willing to grant the required permissions or run the Recreate DB Users utility, which can grant them or clean up workstation users carried over from the old box. The documentation (MRG) that would have helped is the "Database Installation Guide". This guide should have been followed for the setup of the new SQL box. It describes how the thick client accesses SQL, what permissions it needs, and the prompt you received. Based on the security concerns you brought up in your post, I would also recommend some good information about the SQL authentication in the OnBase SysAdmin guide as of version 13. Open a version 13 or 14 SysAdmin guide and search for "Changing Database User Name Passwords" and "Disable workstation account creation". The changing of database user names was available well before version 13, but it was only covered in a separate manual before. I hope this helps anyone who may be visiting this blog.

    ReplyDelete
  4. hsi is username and password is wstinol as many have said, both are HARD-CODED into the .exe. Realistically, it doesn't need full DBA, but it does need to create the sql user account for the computer that the client is being logged in from. it's stupid as hell.

    ReplyDelete