OnBase Security Tips

We live in an age of internet connectivity, which perforce means we live in an age of internet attacks. The news is full of stories of security breaches and stolen information.

Your OnBase solution contains important and often sensitive data, much of which may require strenuous security measures for compliance.

How, then, can you make your OnBase solution more secure, without a complete redesign of your infrastructure?  Are there easy steps that increase your security without overcomplicating your system and without requiring a huge allotment of time?  Yes, there are, and today we’ll go over a few of them!

1. Secure the Manager & Administrator accounts – The Manager & Administrator users are built in accounts for OnBase which have god-like powers over your system.  A compromise of these accounts can be very serious indeed, but the accounts are easy to secure with just a little thought and effort.
2. Change the passwords – The standard passwords for the Manager and Administrator users are well-known, but you can easily update them to something specific to your system. Be sure to record the passwords somewhere, however – KeyMark support will not be able to get you back into the system if your passwords are lost!
3. Don’t do general maintenance with the Manager account – There are very few actions which require the Manager account. For nearly every Configuration action, it’s sufficient to be part of the Manager User Group.  Therefore, the Best Practice for security is to NOT use the Manager Account at all, but rather to create specific accounts for management tasks, and assign them to the User Group.

You can get as simple (one alternate account) or complicated (multiple accounts for different actions, such as a UserManager that only works with Users and UserGroups, and a WorkflowManager account solely responsible for Workflow Configuration, etc.) as you wish, but just using a different account, unique in name and password to your organization can greatly increase your security.

TIP:  After creating the new user, login to OnBase manually as that user one time.  A new user will always have to change the password on login, and the service will not start until this is done.

Don’t Use the Manager or Administrator Account to Run Scheduled Tasks:

Windows Services to run Scheduled Tasks, such as DIP or COLD imports, scheduled Sweep or Commit actions, require an OnBase login. Many systems default to using the Manager account, but this grants the Windows Service wide and extensive powers in your system.  It’s much more secure to create a new account, specifically for the service, such as OnBaseDIP or OnBaseCommit, with its own strong password, with which the Windows Service can login to OnBase.

But just creating a new user doesn’t do all the work – you also need to be conscious of what User Group the user is assigned to, and take steps to ensure that the user does not have access to any process, document type or other OnBase component not specifically required to run the Windows Service.

Don’t make the service user part of the Manager User Group!  Rather, make the user part of only those groups that have access to the specific Document Type the particular process will import.  If the OnBaseDIP user is only running DIP, and the DIP process only imports DocTypeA and DocTypeD, make the OnBaseDIP user part of a user group which has the Privilege to login to the Thick Client, but not the Web Client, and give that user rights to Document Import, but not Scanning, etc.  Remember the Principle of Least Privilege, and  your system will be that much safer.

Secure Your Application Server by Using Impersonation

By default, IIS runs all services as the user specified by the Application Pool.  If that user is Network Services or the Application Pool User, a skillful attacker can take advantage of these well-known and standard Windows account to get into some low-level areas of your system. However, if you use Identity Impersonation when setting up the Application Server, you can greatly increase the security of your system.

The user account you will use is unique to your environment, and the account itself is not identified in any web activity, making it much more difficult for an attacker to leverage that user to get into your system.  As always, give that user the least amount of access and rights possible in Active Directory and OnBase – but make sure that the user has access to the Disk Groups and, if you are using Active Directory Authentication to login to OnBase, rights to query Active Directory for Group Memberships for other users!

Also, note that I specify the Application server, not the Web Server for the Identity Impersonation.  The Web Server never interacts with Windows directly, only with the Application Server, so using Identity Impersonation on the Web Server does not improve overall security.

Use Complicated Passwords in OnBase

Starting with OnBase 14, OnBase is installed with two standard System Password Policies, which can be copied and modified as required.  By default, the Medium Security Policy is applied.  The Medium Security Password Policy includes these features:

• No more than 2 characters can be repeated consecutively
• Passwords must be a minimum length of 8 characters
• Passwords expire the first time users log on
• Accounts are locked after 5 failed attempts to log on
• Locks on accounts with too many failed attempts to log on are released after 15 minutes
• Accounts are locked after they are idle for 180 days

It may be more advantageous to your system, and is certainly more secure, to enforce the High Security Policy that OnBase provides, which includes these features:

• User names cannot be embedded in passwords
• Passwords must be a minimum of 15 characters in length
• Passwords cannot be reused within 5 password changes
• Passwords cannot be changed more than once within 24 hours
• Passwords expire every 180 days
• Passwords expire the first time users log on
• Accounts are locked after 5 failed attempts to log on
• Administrators must manually release locks on accounts with too many failed attempts to log on
• Accounts are locked after they are idle for 60 days

What other methods of increasing security have you found to be effective?