Welcome to Summer! July continued to be a busy month here at SiFr. We celebrated our company birthday, planning our second company retreat, successfully wrapped up another Intune project, and just overall feeling grateful with the wonderful weather that is finally kicking it in style after a long, cold spring.
This month, we continued the trend of helping clients secure their on-premises Active Directory environments, but it’s not interesting to rag on about the same topic all the time. So, for July, we wanted to highlight a very specific way on how we help improve AD environments, and that’s around Identity Lifecycle Management.
What is Identity Lifecycle Management (ILM)?
We don’t want to reinvent the terminology, so we will quote what Microsoft says about ILM.
“Identity Governance helps organizations achieve a balance between productivity - How quickly can a person have access to the resources they need, such as when they join my organization? And security - How should their access change over time, such as due to changes to that person's employment status?
Identity lifecycle management is the foundation for Identity Governance…Identity Lifecycle Management aims to automate and manage the entire digital identity lifecycle process.”
To put simply, ILM is the process around how your users and devices get access to tools and documents so they can do their job, and how that access is terminated when they change roles or leave the organization.
Common Identity Lifecycle Problems
Now that you know what ILM is, see if you recognize some of these issues which is what we most commonly see at client environments:
IT has no insight into what HR is doing and vice versa. Data exists in data silos with HR maintaining one set of records, and IT maintaining another set of records.
User’s roles, titles, departments information are manually inputted by HR and then again by IT.
At every step of the user’s career (onboarding, job change, offboarding) it requires a Help Desk ticket from either HR or the staff’s manager to request access or change.
As users change roles, their permissions to access resources are wrong, resulting in more support tickets to resolve and lost productivity.
Often, user accounts are not disabled when staff leaves the organization because HR and IT are, again, two siloed departments that don’t share their employee data set.
Users might need to manage multiple pieces of login to various systems to perform their job. Logins are then forgotten, resulting in more support tickets to reset and gain access again.
Resolving Identity Lifecycle Problems
If you’ve recognized some of these issues, you must be asking yourself where to start to resolve the issues. What we advise as step one, is always start at the source. That is, where is the source of your data?
For most organization, the most appropriate department to manage employee data would be HR. HR data is usually used for payroll, taxes, and other legal requirements surrounding employment. Because of the various legal requirements, HR data is also the most accurate source for employee data.
As you can imagine, if your employee’s logon name is wrong, they may or may not care. However, if their name is wrong on their pay cheque? You can bet they will care. The most reliable data source is what we call “source of truth”, and any time you can minimize manual data input from one system to another, you can minimize errors created by manual process.
So, how do you begin to utilize HR as the source of truth for your IT Identity Life Cycle? You start by realizing AD is a directory.
Active Directory Isn’t Just Used for Authentication
We talked about this in our Unlocking the Power of Active Directory blog post. For most organizations, Active Directory is thought of as the core of user authentication. You have your username and password, users can logon and do things.
In fact, Active Directory is just as its name implies, a directory. It is built on Lightweight Directory Access Protocol (LDAP) after all.
When you look at the properties of an AD object (and in this case we will focus on user objects), you’ll see attributes like “Title”, “Department”, “EmployeeID”, etc. These attributes become very powerful when utilized properly for Role Based Access Control, or RBAC. For example, how do you know if a user can be granted manager level rights to an HR application? If the user’s job title and department is Manager of HR, then it seems rather obvious.
Leverage Automation
You may or may not already know about the attributes in AD or use them in some fashion. But, as we covered earlier, if manual input is how these attributes are obtained, they may quickly become erroneous depending on how reliably your HR department communicates with IT, or how good the IT team is at data entry.
In fact, there was a Reddit post recently that one user’s company is still filling out paper forms, incompletely at that, and expecting IT to complete the various onboarding tasks. Yikes. Not only is manual input labour intensive, time wasting, but it is prone to human errors.
What we help organizations do, is to automate the entire user identity lifecycle, from onboarding, job changes, and offboarding.
Through automated processes, whenever HR adds a new employee to their HR system, this change is flowed through to IT (all without a help desk ticket being manually created) to:
check for duplicate user already in the environment.
create the AD user with a secure password.
email the user’s manager with the login info.
create the user email.
provide user access to all the systems and folders through Role Based Access Control (RBAC) role groups.
Similarly, when a user’s job changes, the HR system information flows through and:
updates the user’s job title, department, manager information
update user access role groups
When HR terminates a user, a similar but reverse process happens that:
disables the user account
remove their access permissions
mark the account for deletion
HR is happy since employee onboarding happens automagically and they don’t have to remember to create any additional help desk tickets.
The hiring manager is happy since the employee will have access on the first day, minimizing delays in getting the employee productive.
IT is happy since they didn’t have to perform any manual administrative task that take them away from other more innovative initiatives.
The employee is happy since they just went through an effortless onboarding process.
What does all this happiness really mean for an organization?
Increased productivity
Reduced costs
Reduced errors
Increase staff satisfaction and retention
Reduced staff burnout
Now, we all know money can’t buy happiness, but happiness does generate value and profitability. On top of it all...(oh yes, there is more) your environment will be more secure with a reduced attack surface.
Did you find this post helpful? If you want to chat more about your organization’s identity lifecycle processes, contact us.
Comments