I worked at a small company that deployed Active Directory in the late 90′s. We used AD as a central authentication and authorization directory for many things, like desktops, key applications, VPN access, and so on. The company grew quickly. We had multiple lines of business, each with their own “IT” competency, in addition to a central IT group who managed Active Directory and the other central parts of the organization. As time went on, these vertical business units became more sophisticated; managing servers and applications for their specific business area. Across the enterprise, AD became the standard authentication and authorization mechanism for servers and applications, including in the lines of business. Relying on AD gave the business units key advantages:
- Central provisioning of user accounts by the IT helpdesk
- Ability to reliably disable terminated employees from a single place
When the business set up a new application or server, they would request a new AD group be created, with the group membership delegated to a business level administrator. The new server or application would be configured to rely on AD for authentication and the new AD group(s) to grant permissions. This worked well for many years.
Until we were bought. We were bought by a much larger company with much more mature process and security requirements. In particular, each “permission” needed to have an identified owner, and a period revalidation that all employees with that permission still require it. The requirement was very sensible and did not seem, on the surface, to be problematic. After all, we had consolidated all access permissions into AD. Complying with the new requirement seemed like it would be easy until we started to map it out.
We quickly realized that we had a mess on our hands. Over the course of a decade, several thousand permission groups had been added by the business areas. Each time an application was updated that required separating user permissions out a bit differently, a new set of groups was requested (or a mix of re purposing existing groups and requesting new groups). Existing groups not reused were simply abandoned.
There was no documentation of the permission set that a given group provided. The business units had simply taken the AD permissions and leveraged them as needed. For example, one business unit had an application they built which used AD groups to assign permissions within the application. A specific section of the application was built for server administrators in that business unit. The team subsequently rebuilt a number of Windows and Linux servers, using the same AD group used by the application to provide administrator access to those servers.
The plan to consolidate authentication and authorization into Active Directory was a noble one, however, the lack of a solid process to map AD groups to permissions and the dependencies of systems and servers to AD created a serious problem. This gap created a circumstance where employees may have had the opportunity to access systems or applications with permissions that they should not have had.
Don’t become complacent with technology like we did. Ensure that robust logical access policies and processes exist, as they are safety net to avoid serious problems. A good consideration of risks and use cases would have easily identified the gap. But, so would a consideration of how to re-validate employee access to permissions in order to comply with a company policy.
