Reference Users – An Underestimated Risk
“Meet our new team member, Sarah. She’ll be needing same privileges as Gary, please.” What’s that noise, you ask? Oh, those are just the alarm bells ringing at the sound of this request. Today, we’re going to explore the concept of reference users (also referred to as user templates) and discuss why they are a really bad idea.
What Is a Reference User?
We all know what reference users are, even if we don’t know that that’s what they are called. The story usually goes something like this: A new person – in our case Sarah – joins the company. The IT department now has to create a user for her in order to give her access to resources specific to her department.
Since the admin does not know which access rights Sarah’s position requires, he asks Sarah’s manager, who replies: “Oh, Sarah‘s job is the same as Gary’s.” So the admin simply duplicates all of Gary’s accounts to create Sarah’s user for Active Directory® and SAP®.
This means that Gary functions as Sarah’s reference user, or user template. Once the admin has adapted her personal data, the Gary-duplicate becomes Sarah’s new user account.
Quick and Easy Fix: Copying Reference Users
There is a reason, of course, why admins like to duplicate existing users to create new ones: it’s fast and it’s easy. Not that creating new users in the AD is overly complicated – but it’s more than a click: Admins have to use the server manager to make a couple of configurations, e.g. to assign the new user to the correct groups and organizational units.
The larger the company, the more it takes to manage all those accounts and rights. The “quick and dirty“ method of copying a user in the Active Directory® is literally done with a single click:
At first glance, this method seems pretty great, doesn’t it? Not only does it save time, it also gives Sarah all the privileges she needs for her job at one click.
Here’s the thing, though: Do you really think Gary and Sarah need the 100% exact same access rights?
Reference Users in SAP
SAP generally supports the use of reference users as a means to classify users. However, SAP also explicitly points out that users can/should only inherit other user classifications if:
no additional roles or profiles are created for it
it is not manually classified
Why Are Reference Users a Problem?
The reason why reference users pose a security risk is a fallacy admins often hold to: While they think they are merely copying the reference user’s current departmental privileges for the new user, what they are really doing is transferring all of Gary’s privileges, which he collected throughout the years, to Sarah – including access rights for various departments and branches, as well as special project-related rights.
Too Many Privileges = Security Holes
The longer reference users are used, the more chaotic access landscapes become. Ask any IT officer and they will confirm this thesis. One reason why reference users are a problem is that they endanger internal data protection. Because, if nobody is able to trace who has access to what resources and data anymore, the risk for employee data theft rises significantly.
The next issue is external attacks: The more privileges a user has, the more catastrophic the consequences of malware or ransomware attacks and phishing mails can be.
Furthermore, companies who fail to manage their permissions professionally will sooner or later find themselves on a collision course with compliance regulations.
Access Management Software Makes Reference Users Redundant
Administrators use reference users to save time when creating new users. But there is another way to do this without compromising security: Not only will an access management software make reference users unnecessary, it will also ensure that access structures are built in accordance with compliance policies.
Profiles Instead of Reference Users
The motivation behind using reference users is fairly simple: copy-pasting saves time. The access management software tenfold uses standardized rights profiles to replace the copy-pasting process. These profiles only have to be set up one time. Once that is done, they can be used as needed to assign access rights to users automatically across systems (e.g. Active Directory®, SAP® etc.), based on user attributes such as department or location. This makes duplicated users unnecessary.
What’s more, users can request access rights they deem necessary themselves via tenfold’s self-service function. As part of a workflow, data owners can then confirm or reject these requests or set a time-limit for them, which is especially useful for project-based work. You can also modify the default privileges contained within profiles, which is one of the features that sets tenfold apart from inflexible role-based systems provided by competitors.
Watch Our Demo Video to See tenfold in Action!
Profiles Remove Expired Privileges
So far, we have learned that tenfold assigns the appropriate access rights automatically. But what about all the unnecessary privileges that existed prior to tenfold?
No problem, tenfold takes care of this issue as well: Once installed, the software compares all current standard privileges with its profiles and updates those privileges accordingly. Sound good? Well, it gets better still. While the initial alignment of privileges is an important first step, it is not enough to carry us safely across the flowing river of access rights – which is why tenfold comes with another safety boat: the user access review.
As part of a user access review, data owners are “forced“ to regularly review all permissions they are responsible for and to either reconfirm or remove them. There is also a third way of removing superfluous access rights, which we have outlined for you here.
Software Revokes Access Rights Automatically
What happens to a person’s privileges if that person changes to another department or leaves the company altogether? tenfold has a solution: it simply revokes the privileges automatically on the set leaving date. For department changes, tenfold can be set to revoke permissions after a transition period.
For instance: let’s assume Gary wants to train his successor Sarah before moving on to his new department. In this case, tenfold will see to it automatically that Gary gets to keep his old privileges and gets those for his new department for the duration of one month, based on predefined profile settings.
At the end of the 1-month transition period, tenfold automatically withdraws Gary’s old rights. And do you know what? During the whole process, our admin didn’t have to lift a single finger.
Best Practices for Access Management In Microsoft® Environments
Our in-depth guide explains how to manage access securely and efficiently from a technical and organizational standpoint, including tips for implementation, reporting and auditing.