17 Jan Challenges in implementing lifecycle processes for user accounts
“Hey Joe, I need a quick user account for the external person sitting in the meeting room who is supposed to configure the firewall” – source unknown.
There is no such thing nowadays? Far from it.
In our blog post for this month, we’re looking at the topic of user lifecycle processes. In every company, employees come and go, employees get married, go on parental leave or get sick. You would think that user lifecycle processes would be in place at every company and standardized and automated for efficiency and security reasons.
As we have intensively looked into the topic at some of our customers last year, we can say, even in 2022, the topic is not satisfactorily solved in every company.
In this article, we would like to address the most important aspects around the topic of user lifecycle, but we make no claim to completeness. It must also be clear that every company has different requirements and prerequisites. Therefore, we do not present a concrete solution, but would like to provide food for thought for finding your own solution. We take the perspective of the Active Directory team.
Before we go into more detail about some of the aspects, here are the most important questions to answer for yourself when implementing user lifecycle processes.
- Who “hires” employees (often differentiated by internal and external employees)?
- Which is the leading system and in which systems do user accounts have to be managed (HR, accounting, IAM, AD, AAD, SAP, etc.)?
- What are the interfaces to other processes (hardware, software, facility management, accounting, etc.)?
- Which user account types do I need (internal, external, administrative, technical user accounts, etc.)?
- What data/attributes do I need/want to maintain for the different account types?
- Which of these are standardized, which are freely selectable?
- Is the organizational structure available and how should it be mapped?
- Who is allowed to apply for which account type? Are processes to be fully automated (e.g. the creation of the user account in AD is controlled by change in the HR system)?
- Who is responsible for the (technical) user accounts. What happens if a responsible employee leaves the company?
- How does the employee receive the access data?
- How can an employee have the password reset?
- How do you deal with longer absences due to parental leave or illness?
- When can a user account be deleted? How long must the user’s data be retained after leaving and how is this ensured?
- Is it possible to ensure that the processes are lived 100%, or do you have to build in a “false bottom” (e.g. regular scanning for inactive user accounts)?
Definition of the parties involved
From the first questions, it is immediately apparent that the topic of user lifecycle processes cannot be completely solved from within the AD team and that a great deal of coordination is required. Therefore, it is first advisable to be aware of one’s company.
First of all, it is necessary to query the lived practice and, if necessary, to write it down. Which processes are already in place, what is their degree of maturity, and which are perhaps missing completely? Are all the necessary parties already involved or have the requirements been defined? From our experience, organizationally (at least) the units HR, Provider Management, Facility Management, Information Security, Compliance/Legal and Data Protection need to be involved. On the technical side, these are (at least) the Client, Collaboration and Service Management teams (for the Request Fulfillment Portal, see below).
If not all applications are connected to Active Directory or use their own user management, the corresponding application teams should also be involved.
In larger environments with multiple directory services and non-integrated applications, the question must be asked whether a full-blown identity and access management system is not necessary.
Scope and attribute definition
From the discussions with the parties mentioned above, on the one hand, the different types of accounts that need to be managed and on the other hand, the attributes that are mandatory or useful to maintain in the process.
Below, as a starting point, the list of typical accounts in an Active Directory environment and the typical attributes:
It is often useful to define default groups that give users permissions to standard resources such as generally accessible file shares or for applications such as Microsoft Exchange or Sharepoint.
From the previous definition, you can see which processes are necessary. As a rule, this is for each account type: creation, change, deletion.
The change process is usually divided into several subcategories, because not every attribute can be changed in the same way. For example, it is usually allowed for the employee to request the change of his/her phone number by him/herself, but a position change is controlled.
To go into detail about every process at this point would go beyond the scope of this article. There are also entire books on the subject of process design, which is why we will not go into further detail here.
Even though this blog is a non-technical topic, at least a little bit of technology should be covered 😊
Leading system: HR
Let’s assume that we consider the creation process in an organization whose leading system is the HR system:
The first starting point for creating new user accounts in Active Directory would be to transfer the new employees from SAP to Active Directory using a regular batch job. Technically, there are a number of ways to run a script for user creation on a regular basis. This can be the scheduler of the operating system (task scheduler in Windows or cron in UNIX/Linux) or a job scheduling tool. This means that a new employee in the company only has to be manually entered once.
Leading system: Active Directory
If, for whatever reason, no leading system from HR can be used, it is also possible to implement a web portal developed in-house or to link the automation to an existing request fullfilment portal. It is also conceivable to implement a workflow in which a supervisor approves certain actions.
The entries can be validated via a web portal, so that the majority of incorrect entries can already be excluded here. In addition, default values such as addresses of company locations can be stored in selection fields and thus be set uniformly in the user accounts. This is especially important for attributes that are visible in the Exchange address book in Outlook and have an external effect and whose correctness facilitates cooperation within the company.
An example solution when using a web-based portal and an automation server from which the scripts are started could look as follows:
This is quite a long article for a topic that everyone actually already lives. But the devil is in the details. Do you have everything under control?
Sieh dir diesen Beitrag auf Instagram an
Sieh dir diesen Beitrag auf Instagram an
In this article on IPSec, we want to pick up our March 2019 article ESAE Series Part 5 - Windows IPSec and add some additional considerations. As written about in this post IPSec (short for "Internet Protocol...16 May, 2022
After our last blog articles dealt with more general infrastructure topics (user installation, server deployment), this time we would like to focus more on a security topic again...19 April, 2022
Today we are pleased to announce that we have partnered with SpecterOps to offer their first commercial product BloodHound Enterprise in Europe...17 March, 2022