Logins and their associated passwords have been used on computers since almost the beginning of time. And with this need for authentication, every software platform has tried to make it easier to grant appropriate access to resources like file shares, email, and applications. Managing a user’s identity is important, with many different software companies implementing their own solutions.
The problem is too many passwords. In addition to all of their personal passwords, the user may have a network password that grants access to email, the intranet, the corporate Wi-Fi, and all the applications that they need to do their job. Not to mention all the passwords for online services, personal passwords, etc.
Wouldn’t it be great if OnBase could piggyback on this authentication mechanism and save users the trouble of remembering yet another password?
Your OnBase system provides a few different ways to verify a user is who they say they are and to grant them rights. Since your Kiriworks Customer Care Team gets these kinds of questions quite a bit, I think it’s helpful to take a look at how OnBase works be default, and then investigate other options that you could add on top of that.
How do I handle Security today?
In OnBase Configuration, with the –ROMANZO switch applied, head on over to Utils > Network Security:
As you can see, there are a total of five options (in OnBase v12 and above) for you to choose from.
!WARNING!
Undoing or changing these security options is not easy and requires my team and Hyland to make some ugly database changes, so please test your proposed changes in your Test system before you attempt a change in Production! In the above example, notice how the interface doesn’t let me switch this from Windows NT Security to anything else except Active Directory? I can’t even go back to Normal System Security without some assistance from Hyland, so please be aware of this limitation.
“Normal System Security” (The Default)
This is what we commonly refer to as “OnBase Authentication”. If you haven’t changed anything, the database and clients authenticate a user as follows:
- User signs into the Thick Client, Unity, or the Web with a username and password
2. The client they are using queries the hsi.useraccount table in the OnBase database, looks for the name entered (username column), and compares to the stored password (encryptedpassword column).
3. If there’s a match, another query is generated that makes a list of groups that the user belongs to. Each group can be configured with different rights: Being in the Web Users group, the Accounting group and the Scanning group might grant access to the web server, allow them to review accounting documents, and scan new documents in (respectively).
It’s a pretty simple design, and works well! Other forms of authentication build off of this security structure, but always have to have a way to map a login to OnBase groups so that permissions are assigned correctly.
“Windows NT Security” – Matching Groups
Introduced early in OnBase’s lifetime, the Windows NT Security option came about at a time when there really was a Windows NT to talk to. Since Windows 2000, this has been used in conjunction with Microsoft’s Active Directory solution to provide an integrated login experience for OnBase users using LDAP queries. The process is as follows:
- Using the currently logged in user’s Security Identifier (SID), we query AD and get a SAMAccountName (“SECURITYMICRO\Gwheeler”, for example).
2. Using this SAMAccountName, we query AD again and get a list of all AD groups that this user belongs to.
3. OnBase compares the AD groups to a list of its own OnBase groups, and if there are matches, they gain the permissions of those OnBase groups.
This is a very simple 1:1 mapping solution that requires a network administrator to create security groups in Active Directory that match the OnBase user groups exactly, then add the users to the groups in Active Directory.
What is nice about this method is the users no longer need to maintain an OnBase security account and associated password: the domain account is enough. One less password, one less helpdesk ticket!
When logging in to OnBase with a user name that doesn’t exist in OnBase, the user is automatically added to the OnBase database and attributes like Full Name and Email are added.
This approach does not come without caveats: Group names must match character-for-character case-sensitively (which makes it somewhat inflexible for future changes), and due to the somewhat older method it queries Active Directory it has some interesting quirks.
The biggest problem our customers have with this method is that it requires OnBase administrators to have access to create security groups in Active Directory. Depending on your domain functional level and the operating system of your servers, this could mean either giving access to a domain controller, or installing ADUC/ADDS on a workstation and supplying an account to manage group memberships.
Alternatively, you can train network administrators on what groups have access to in OnBase.
None of these solutions are ideal (although we see all of them across our customer base), because it either means having OnBase admins working directly in AD, or AD admins in charge of OnBase. For some companies, this isn’t an issue. However, this is a non-starter for other companies for compliance, auditing, or security reasons.
Stay tuned for Part 2 of this guide, where we discuss Novell Security (which you shouldn’t use), LDAP security (to connect to all types of identity systems), and the newest option in OnBase 12+, Active Directory Security!
