Definitions
You’ve probably heard the term “RBAC” – Role Based Access Control. It can manifest in something like a password reset web portal – i.e. users who have “Password Reset” Role can access and use such web portal. The role itself can be established by simply having, let’s say an Active Directory group “RBAC Pwd Reset,” though there are many other ways to establish an RBAC relationship.
Today I’d like to talk about a less used term – “LBAC” – Location Based Access Control. Let’s say we have the same web portal that I mentioned in the RBAC description above. If we’re a large organization, we probably don’t want an absolute “password reset” power – i.e. a helpdesk user should not be able to reset password of a domain administrator. This is where location-based segregation comes in, and boy can it get messy.
The Problem
I’ve used Tools4ever‘s UMRA to build countless automated account provisioning and web-based delegation systems. There’s a pattern I see all too frequently in how these projects unfold:
- Implement automated account provisioning (biggest ROI)
- Implement delegated web portal (i.e. password resets)
Here’s the problem: usually step #2 doesn’t come into the picture until step #1 is completed. Depending on how #1 was implemented, #2 will either be a graceful and simple implementation, or it will be a complex mess of a spaghetti plate – all because of LBAC.
Clean LBAC Example
Let’s say our automated account provisioning system enforced the following OU structuring:
/Users/<Building Code>/<Department Name>
…this makes it very easy to structure LBAC rules, i.e.:
- Password reset can only be performed against users in the same <Building Code> as the user performing the action
- Password reset cannot be performed against users in <Department Name> “IT”
Similar relationship could have been established using group memberships instead of OU structures and through other ways too. As a rule of thumb, whichever LBAC approach is easiest to comprehend is the best one.
Dirty LBAC Example
Let’s say your automated account provisioning is more primitive: everyone goes into /Users/Staff OU and gets a generic “Staff” group membership. Since the automated account provisioning implementation is already rolled out, you don’t get the luxury of making big changes to it, at least not for a while. So what do you end up doing to make your delegated web portal LBAC work? Well, here’s what I’ve done in the past:
- Set up SQL Table “LBAC” with columns: Location Name, Governing Users Group
- Set up according AD groups
- Find means to connect “Location Name” to your staff accounts – usually through another AD group membership
- Establish process (manual or automated) for placing staff accounts into appropriate AD groups to maintain this LBAC system
Instead of being a graceful 100% hands-off system that relies on no additional resources, besides the OU structuring that’s already there, you now get this beast.
Conclusion
Old saying goes “measure 7 times, cut once.” This couldn’t be more true when it comes to LBAC (and usually how that interacts with RBAC). If you plan your delegation at the same time as you’re planning your automation, you just might save yourself a lot of time and money down the road.
BetterIDM 