AD Integration

[Greg_Garvin]

I see this quote from the network security MRG regarding Active Directory Integration:

"Group mapping and user authentication is achieved using the Active Directory Security ID
(SID) of the group and user logging in, so name matching is not required with Active
Directory."

Does this mean the OnBase user ID and the Active Directory login ID do not need to be the same?

And if they don't need to be the same how does the OnBase user account associate with the AD user account?

Thanks

[Greg_Garvin]

I think I have the answer to the first question....but here is my next question:

There is not currently a common, unique field between our OnBase user accounts and our AD user accounts.   We're considering changing the login name on our OnBase user accounts to match our AD login IDs....Is this a manual process or does Hyalnd support have an automated way to do this?....possibly thru the database?

After the user accouts logins match I'd like to create 1 AD group that contains the AD user accounts of all OnBase users and grant this group the right to just authenticate to the OnBase application...all access to OnBase processes, doc types, WFs, and any other operations would be controlled thru membership in OnBase groups the way it is now....is that a doable scheme?

thanks

[John_Anderson4]

As you would expect, OnBase needs some way of mapping its User ID to the proper user in Active Directory. If there's no field in AD that corresponds to the user name, I'm pretty sure you can't do the mapping. With the new "Active Directory" integration in OnBase 12, the actual "user name" fields don't need to match, but it still needs SOME way of figuring out which user is which.

Long-term, you are probably best off renaming your OnBase accounts so they match AD. It just makes things a lot simpler. I'm not aware of an automated way of doing this, but if you have too many users to do it manually I'm pretty sure they could come up with something for you.

I've done a security scheme much like you describe - just have everyone in one "common" AD group used for authentication only, and administer the actual security within OnBase. It works just fine. One thing I will say is that the new "Active Directory" integration has some options that may make you reconsider. In the past, your AD group names needed to match the OnBase user group names exactly. This is not the case with the Active Directory integration. You can set up mappings, so if someone is in a certain AD group, they are automatically mapped to be members of a set of OnBase user groups. It looked cool in the class I went to on it, but I haven't had the opportunity to use it for real yet.

[Anthony_Boyd]

I'm not sure what version this was added (I am thinking v11 or v12) but they now have a "Authentication Only on Auto-Logon" so you no longer need an AD group just for authentication.  We have this option enabled so AD handles the authentication and we manage all other access/rights with native OnBase groups.

[AdamShaneHyland]

Hi Greg,

From the sounds of it, you found the answers to your question.  You are correct that the with OnBase 12 using the Active Directory integration (not Windows NT Security), the group names do not have to have a one-to-one mapping between OnBase and AD in order to allow users to log in.  This is as mentioned becuase OnBase uses the Active Directory Security ID which is a unique ID to identify the particular object in AD. 

The same is true with users.  Now with users, things work a bit differently.  As Anthony mentioned, there is an option to allow OnBase to bypass any group mapping from AD an only use it for user validation (meaning to verify that user is valid in AD).  This option would require the OnBase admin to assign all users to their respective groups.  Obviously this option provides a lot of overhead in administration of your users and was only designed in cases where AD admins do not want to manager OnBase groups through Active Directory, but autologin is expected.  It is possible as you requested to add all AD users to a single OnBase group which will allow for user's to authenticate into OnBase while managing specific permissions through the OnBase User Group administration.

There is another user option which will allow you to map the username to some other AD attribute instead of the sAMAccountName.  By default this is the attribute which OnBase uses to authenticate the user against AD.  For instance, the user might log into OnBase using JDOE, but in OnBase you have the user configured as JOHNDOE.  The value JOHNDOE might be associated with a separate attribute in AD.  Through the use of the Active Directory Username Mapping Attribute, the OnBase admin can specify a different.

As John has mentioned, there have been a lot of enhancements made to the Active Directory integration in OnBase 12.  There is no need to have a one-to-one group mapping.  Since we now work off of the SID (a unique ID), it is not possible to drag and drop a domain group (or many domain groups) from AD to an OnBase group(s) (ie we now support many to many relationships instead of one to one).  This means that anyone who is a memeber of the AD group will then be added as a member of the OnBase group.  Additionally, there is an option which will allow for OnBase to automatically migrate your Windows NT configuration (ie get the SID's for users and user groups and configure the necessary user to user group mappings) to the AD configuration.

Hope this answers some of your questions.