Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth, I'm the director of the Practice Identity and Access Management here at KuppingerCole Analysts. And we want to talk about identity and access management, more precisely about IGA. And therefore I've invited Martin Kuppinger, he is the principal analyst and one of the founders here at KuppingerCole Analysts. Hi, Martin. Good to have you.
Hi, Matthias. Pleasure to be here again.
It's great to have you. And we want to talk about a topic which is not about immediate products. No massive trends, no future looking, no trend that needs to be covered. We want to talk about the real life. We see many organizations in the field that are heavily relying still on AD, on Active Directory, on premises Active Directory and actually they are quite happy with that. They are using that for 15 years, 20 years now, but now they reach a point where they need to get better for reasons for an audit, for doing recertification, for reducing the access rights. And then they consider thinking about adding an IGA on top of AD. And in the first place that sounds good. We have a data source which is AD, which stores the “identities”, quote unquote, and we add processes on top of that. What needs to be considered to do this properly, Martin?
Yeah. So first, maybe a quick history of mine. Before starting KuppingerCole Analysts, I've been authoring quite a stack of books around Windows Server and Windows NT before that, and even before that [...] and other stuff and NetWare and so on. So I have some deep insight into these environments, a deep understanding. And when I look at whatever advisories I did over the past two decades, then again and again, we were talking with organizations that said, okay, we have our Microsoft Active Directory and we are using the groups in Microsoft Active Directory to control who has access to what. So a lot of this is done. Some of them then have an IGA tool that sort of sits on top of AD and uses partially the AD groups, so to speak, as an indirect approach, and partially direct provisioning to other systems, so to speak, as the direct approach. And when we look at this then usually in these environments, there are a couple of challenges occurring. And I think these challenges are the ones we need to look at. So basically we have a couple of challenges. The first one is Microsoft Active Directory is legacy, and I think we just can say it that way. It is something which is here, which will be here for quite a while, but it is legacy. So building on a legacy product as a central element in a strategy for identity management, or digital identity, I think this is something you need to be careful with. The second and this is what frequently leads to real problems, is ownership. Unfortunately, Microsoft Active Directory in many organizations is not in the ownership of the identity management team. That means you have two different departments dealing with identity management issues This is part of the challenge. And we can go deeper on that later on. The third point is that this indirect approach, you are using groups in Active Directory that are used for a variety of purposes, not only for the access control to external applications at the end. And the risk of things becoming inconsistent, so what is done in Active Directory is not necessarily what identity management would need, becomes another challenge. And so there are a couple of risks and latest when it comes to governance and understanding what has been done then means you need to aggregate data from two systems into a holistic view, and that makes things definitely also more complicated, more complex also than the entire governance process. As I remember in... many, many years ago, probably 15 years ago or so, I created a slide. And that looked a bit at the defined sort of breaking point between identity management and systems below. So we are controlling in identity management the IGA solutions the identify governance and administration, we are creating accounts and we are mapping these accounts to something which frequently is called then system role, which in fact are exposed sort of groups of entitlements from a low level system. So a global group from Active Directory maps to a system role which is requested. But what happens below that global group in the complex structure of Active Directory or with an SAP business role in the complex structure of SAP. That is frequently out of control of the identity management team and handling this is complex. And so the question is, is it really a wise idea to rely on Active Directory here, or should you better go to direct [...]?
That's true. And when you say identity versus account, I think that covers most of the issues that are behind that. When we say IGA, identity governance and administration, we think of an identity as a more holistic concept, which is then reflected within systems, through accounts, through access rights, through authorizations, and in the end with the right to use and modify data. And Active Directory really is much more and it's really rightfully so, an account management system. It allows accounts...
Yeah, it’s the target system.
Exactly. As a target system, it needs to be managed properly and it has all the beauty and all the shortcomings of the target system. The more you do within a target system, the more delegated administration, especially of authorizations you have, and you do have that in AD, the more problems you gather. And that is what you've mentioned, the more that is done behind the scenes, under the hood of the system, the more you need to apply proper scrutiny to understand what is going on in there. If you do it properly, which would be a fully provisioned system with all insight into the authorizations within the target also visible in the IGA system, the better it gets. But if you start out with AD, which many organizations right now do, especially medium sized organizations that need to add some additional IGA functionality, they need to translate AD into proper identities plus accounts. And that is a challenge.
I wouldn't fully... First, I wouldn't fully agree with your definition of medium sized. So I've seen organizations, there's a couple of hundred thousands of employees doing it that way. So some IAM, IGA tool and Active Directory. Second, don’t understand me wrong. So especially the people listening in that are maybe coming from Active Directory site. I'm a fan of Active Directory, I like Active Directory. I've written hundreds, literally hundreds of articles about Active Directory, several books about Windows Server, etc. So I think that it's a valuable system. It's a good system. There are a lot of positive things, but we should use it for what it is built for. And that is, I think, the important point. And sometimes in these conversations the argument comes that, oh, but we need to create an exchange mailbox and stuff like that in the process of creating and user in AD. This is something you also can trigger for most IGA solutions. So it's not necessarily that you say I need to do everything in AD because of that, it's really a weak argument. I think there's a lot of history behind because, AD in the beginning, was more an infrastructure directory. So at some group policies etc., of infrastructure management, etc. in there. So it's not a pure IAM system. I think for Azure Active Directory or Entra Azure Active Directory, it's very clear that is an IAM tool and if it's not in the hands of the IAM team, something is wrong in the organization. Full stop. Azure AD must be in the ownership of the IAM team. There's no valid other option. For AD we can discuss due to the history, but in the current common use it also is better in the IAM team which would resolve one of the challenges I've mentioned, the organizational one. So it is that there are different points we need to look at. But you also brought up this point and I think this is an interesting one about identity and account. I personally still would love to see all of us thinking in a three level approach, which is the person with identity or identities and all of them having accounts. Because at the end and when you look at more than just employees and workforce IAM, then you quickly end up in the scenarios where you have multiple identities. So you have, in many companies you have the option that employees can procure certain goods that are manufactured by that company like, vehicles or whatever else. And even when they retire they remain there. So they have so to speak a customer and an employee. Or take an insurance company, you can be an employee, you can be a freelance insurance broker, you can be a customer, three different identities of the same person and they need different accounts. Otherwise you end up in horrible segregation of duty challenges. So I think this multilevel thing is important. And yes, Active Directory is about account. It's factually a target system. So I think we... I think there's a charm and there are also some systems which are fully AD integrated. Take whatever, SQL Server from Microsoft or stuff like that, which always had this extremely close integration to it. And that is very logical at the end. But they rely on the AD account, but even exchange and have separate group or make lists, etc.. So it's a bit different. But for other systems which have an optional integration into AD as a directory. I'm definitely not a believer in saying we use the AD groups because of all the points we've mentioned. There are so many, like who owns it, if you have a split ownership, you're in trouble. How do you really do an access governance? How do you ensure that groups are only created for the authorization purposes within identity management and not for different purposes, which then sort of lead to other options for access at the end of the day? And all these things are very difficult to handle. And so my belief is that it's a wiser decision to use a separate tool. By the way, this also allows you a way better migration away because if you primarily rely on Active Directory as a legacy environment, what do you do once you say, It's really not my primary environment anymore? So I wouldn't do investments in my IT overall that are based on technology that is moving closer to the end of life.
Yes. And you've mentioned that topic of ownership, and I think that is also an important aspect finally. Maybe look at as AD is not only an account storage system, it's also an infrastructure directory. It looks at machines, at networks. It might be even there in various instances and tenants that do or do not trust each others forests, whatever. So these are handled within different departments. You've mentioned application entitlements being managed through groups and tightly related to groups in applications and they need to be there. So and you've mentioned the IGA department and I mentioned the Cyber Security Department. When you look at a larger organization with all these complexities that I've just described, what would you recommend when it comes to ownership of the AD systems (with an “s”) at the end and how to get better in applying governance to that?
So, so we have usually nowadays... in modern organization we have the CISO which also owns identity management or digital identity, which owns other parts of cybersecurity. So multiple departments below a CISO. And one of this is the IAM or digital identity department and that should be the owner of the ADs, as long as they are used for any so to speak identity management purpose. Anyway, you're well advised in an organization to have a good concept for sort of not sprawling AD. So I have seen so many organizations which ended up with hundreds, literally hundreds of domains, forests, etc., and frequent and got back from there. So this is something you need to keep anyway under control if you don't have it. So I believe that the identity management department is the best place for that with a clear segregation of what is then done more and more on an infrastructure side, surely that is something which needs to be considered. But at the end, you know, we have a similar challenge when we look at the SAP world, basically the same. It requires then... At the end it requires also a well-thought out target operating model for this part, which defines what is the responsibility of whom. How do you split it up? But I think that the key message for today is really, be very conscious about what you do in the AD or not. It has its place, but there are also things we need to look at from an identity perspective. And I think this all has changed. Also, you know, when I go back, whatever, to Windows Server 2003 or something like that or 2000, then the role of AD was very different. And the maturity of IAM was very different from what we have today. So over these two and a half decades or so, things really have changed and I think this is something we need to reflect. So we can't say, okay, this is all the way we always did it since 2000 or so, but we need to understand that the world has changed and we need to reflect this. And there are so many interesting things also for the AD experts to do. So let's modernize it.
Absolutely. I would fully agree. One additional question, quick answer. Many organizations that are moving to the cloud that have moved to the cloud, they just say, hey, administration of AD is working. Let's add just another connector and let's provision all the accounts that are AD, via ADFS, or however you call it, tomorrow into Azure AD. What would you recommend to those who are using that old paradigm for administering the AAD?
Yeah. What shall I say? You know, that’s I think just the wrong way because you shouldn't invest into the past but into the future. And it means AAD if you have both must be in the lead so that you can gradually retire on-prem AD where you can, in some environments, like in the operational technology, or a factory floor, this may take more than a decade, surely, but I think it's the only way to do it. Otherwise you’re investing into the past and just adding to the challenge of migration you need to solve at some time.
Right. I fully agree. So it should be the traditional way, IGA controlling lifecycle management, access request, access approval and AD and AAD being systems that are provisioned out of there and all of those are properly governed. And then you get to a solution where you also can exchange no longer needed building blocks and that might be one or the other AD. Martin, thank you very much for being my guest today, for talking about that. I think we should continue that discussion and if the audience has any comments, questions, contradicts, please leave your comments in the comment section below that YouTube video or send us email If you're listening to that on any other podcast platform, we are happy to pick up your questions, your comments, your criticism, and use that in upcoming episodes. If you want to talk to us, reach out to us. Thank you very much, Martin, again, looking forward to seeing you soon to have another podcast episode, maybe on an upcoming Leadership Compass. I know that there's something on the horizon. Thanks, Martin.
Thank you, Matthias. And by the way, we are also happy to advise everyone on modernizing the strategy around AD. We have a lot of knowledge there. Thank you.
Thank you.
