One of my favorite features of OnBase from an administration standpoint is its ability to take advantage of the user credentials and group memberships in Active Directory. By default, access to OnBase requires independently managed user names, passwords, and security groups. Enabling Windows NT or LDAP Security allows you to centralize the administration. Administrators can manage access rights more efficiently and users have one less password they have to remember.
It is important to note that enabling Windows NT Security is a one-way operation because it structurally changes the database. If you decide later that you don’t want to use it you can effectively disable it with some setting changes, but the functional link between OnBase and Active Directory will remain open permanently. Likewise, enabling LDAP Security is a permanent change. In addition to the database level change, the naming convention of the groups in AD and those in OnBase must be identical in order for OnBase to link them.
There are several levels of integration available:
NT/LDAP Authentication – OnBase is automatically authenticated with the Windows credentials and group memberships of the user logged into the workstation. User accounts and group memberships are managed in AD. This is the default behavior when enabling autologon.
Interactive User Authentication – The user is prompted for Windows credentials when launching OnBase. This can be useful for shared workstations and is enabled separately for Classic or Core based modules.
Synchronize User Attributes – Updates the user’s OnBase account with changes made to the user’s real name or email address in AD since the last login.
Authentication Only – Restricts OnBase to look at AD for basic authentication only. New user accounts must be created in both AD and OnBase. Group memberships are managed in OnBase.
User Group Authentication Settings – If the Authentication Only option is not in use, removes users from an OnBase group when they are removed from the corresponding AD group.
When enabling NT Authentication for the web client, Hyland recommends setting AppNet to Windows Integrated Authentication, and AppServer to Anonymous Access. Using Windows Integration Authentication generates two hops for every call made through the virtual directory. OnBase can make the call to AppServer via Anonymous Access. If you have other core applications that need to use NT Authentication, you can create a second AppServer virtual directory, set it to Windows Integrated Authentication, and point all of the service locations to this secondary one, keeping the web client pointed to the original one. This would actually help performance, rather than hinder it.
On the other hand, you may wish to disable Anonymous Access entirely if, for example, OnBase is not in the same domain as the user or you need each user to log in with his/her own account for additional tracking and security. Either way, EnableAutoLogin needs to be set to True in the appSettings section of the AppNet web.config file to eliminate the double login with IIS prompt and allow OnBase to pass the AD credentials.
Hyland Resources: 11.0 Network Security MRG
