cancel
Showing results for 
Search instead for 
Did you mean: 

Renaming AD groups when mapped with OnBase groups

David_Chatterto
Star Collaborator
Star Collaborator

Hi,

 

We're using AD enhanced authentication, mapping AD groups to OnBase groups. I was looking to rename most of our groups to follow a standard, however upon testing I noticed the AD group name doesn't update once renamed in the Active Directory - Enhanced window - it still shows the old name. Is this by design? Do I have to remap once I do the renaming?

 

Thanks.

1 ACCEPTED ANSWER

AdamShaneHyland
Employee
Employee

Hi @David Chatterton ,

 

If you are using AD - Enhanced and the OnBase - AD user groups are already mapped, then the OnBase User Group stores the SID (security ID - i.e. unique identifier in AD) for the AD user group.  Renaming the user group in OnBase or AD should not have any effect on the mapping (note, I haven't tested this).  

 

Take care.

View answer in original post

8 REPLIES 8

Hi @Jim Perry ,

 

The value of the User Groups Distinguished Name (dn) that you have highlighted is only displayed in that context when selecting the AD User Group mapped to the OnBase User Group in Active Directory - Enhanced.  The hsi.secprincipal.principaldn is the column in the database which stores this value.

 

My guess is that the only time we capture this value is when mapping the AD User Group to an OnBase User Group which is when we query AD for the User Group properties (Name, DN and SID).  While technically it could be updated in the database, my first question is why would you want to?  Second, I would ask if removing the mapping and adding it back resolves the issue.  

 

Best wishes.

@Adam Shane , thank you for the quick response.

If I remove the mapping and then add back the group it becomes a new group and has to be added back into the configuration for all previously associated items.

The reason we want it to match is for consistency. Whichever field is queried will reflect the same name for troubleshooting so it does not confuse future technicians and security information officers.

No one person needs to know everything—they simply need to know who knows it.

@Jim Perry ,

 

One of the things to note here is that while yes, the name might not match, it is always going to match on the back end. This is because each Active Directory Security Group has a unique identifier. And in order for the AD - Enhanced to work, it uses that unique identifier as the source of truth for what AD Security match to what OnBase User Group.

 

Now, the thing that needs to be done is a true SCIM sync needs to be created and it needs to be released ASAP. I do know that Hyland is working to make the OnBase integrations (i.e. authentication systems) more platform agnostic. And so with that being said, they absolutely need to have this SCIM sync built and put in place ASAP. And another thing, it should operate in a similar fashion to how the current AD - Enhanced works. No more of this whole junk surrounding how the Hyland IdP requires the AD Security Group Name to match the OnBase User Group Name as this requires more security groups to be created thus we run into the Header Too Large issue (thank goodness this was fixed in 2.11.0) stuff again and probably could in the future again.

 

Just my 2 cents of course. 🙂

Hi @Jim Perry ,

 

Thanks for the update.  As long as the SIDs match, that is all that matters with this configuration.  The DN is only pulled during the initial mapping of the AD User Group.  There are currently no other triggers to update the DN of the AD User Group should they change (such as moving the User Group to a new OU in AD).

 

If this is something you would like to see added to the software, you can submit an Ideas request.

 

Best wishes.