OnBase Authentication Security Issue

[Eric_Morris]

We have recently determined that allowing OnBase authentication is too much of a security risk for even our system administrator to have and need feedback for best practices to address this issue. Our sys admin can use OnBase authentication to login as a user and it appears the audit trail does not distinguish between NT authentication and OnBase authentication. Therefore, it allows the sys admin to perform tasks as the individual. So, I need help answering the following questions:

(1) Can we turn off OnBase authentication? If so, what admin functionality will be lost if we do?

(2) If we cannot turn off OnBase authentication or choose not to, does the audit trail differentiate between NT and OnBase activity?

Thanks in advance.

[Marcus_Christia]

[quote user="Eric"]

Thank you for all the responses.

Jose, this is completely about the ability the sys admin has and not what he has or hasn't done. But yes, this question stemmed from the discovery that he COULD login as someone else, perform a task as that person, and we have no ability to audit or prove that it was the sys admin that performed the task.

We have considered having our security team change the passwords to something only they knew, but it is our understanding that the sys admin could change it back to whatever he wants without an audit record showing the change, which complete negates the effort by the security team.

I am curious if anyone feels this level of access by the sys admin is a risk or common practice.

Hi Eric, just to chime in.

This limitation largely only applies to the OnBase (Thick) Client.  It does not apply to the Unity or Web Client by default if they're configured for NT Authentication.

The Web Client is likely what your security team is looking for.  In order to get that client to allow local login, I'm fairly certain you'd have to change the configuration files OR install it somewhere else without the autologin settings, both of which are fully tracked and managed in Windows Event Viewer, traceable from Fiddler and other network sniffing tools, and if you have server-side log scraping, fully auditable. 

There's such a thing as over-security; meaning that there is no way to 100% ensure that something wasn't breached.  At some point you have to settle on whatever's reasonable.  If I as a sys admin walked up to an unlocked machine that was already logged into OnBase, I could perform whatever tasks as that user I wanted.  I didn't change passwords, didn't need to.  So you implement an autolock group policy.  But in the 5 minutes it takes for it to autolock, it COULD happen.

You wouldn't set the autolock down to a minute because then the user would be constantly prompted every time they stopped interacting with Windows.

Specific to the OnBase Client, it does tell you what machine a login event occurred from.  So barring the above scenario (the sys admin went to someone else's machine), if he logged in as JSMITH on his own computer, that's tracked back to him because it's his machine, which we assume JSMITH doesn't have access to and therefore should not be logging into.