Difference between Active directory and Identity and Access managment

user_2861312 0
Viewed 27437

Please excuse me if this question sounds trivial to you. But I am very new the Identity and Access Management. There are multiple tools available in the market from IBM, Oracle etc.

I am from Microsoft background and was under impression that some of the stuff that Identity and access Managment tool does can be done by Active directory.

I am struggling to understand that how Active directory is different that Identity and Access management.

Can I integrate these IAM tools with Active directory?

Is Identity and access management for the internal users which are stored in Active Directory?

And if there are reasons or features that IAM provides (on the top of the Active directory), how does this interaction work? For ex. my server credentials are always checked against active directory. It cannot be checked against IAM database. Does it mean that IAM uses Active Directory as a repository?

active-directory
2 Answers

This is a surprisingly common question, and it doesn't help that many participants in the market like to use misleading terminology to describe their own products.

Think of it like this:

DIRECTORIES, INCLUDING ACTIVE DIRECTORY:

  • A directory is a system that stores information about identities:

    • How the data is physically stored varies and is not too important.
    • Data stored includes user IDs, names, other identity attributes, etc.
    • There may be passwords associated with user objects, but that's not always the case.
    • There may be groups and group memberships, which model what people have access too. This is also optional.
    • Objects in the directory may not represent people at all - you can have computer objects, policy objects, printers, etc.

  • Directories expose this data through network services. Principally, LDAP (lightweight directory access protocol) is used. When combined with SSL or TLS, this becomes LDAPS and is encrypted. This is the main protocol used to search, read from and insert/update content into the directory.

  • Active Directory (AD) is Microsoft's main directory product for corporate use. There is also Azure AD (which is not AD at all, in reality - there is no LDAP service as far as I know) and Active Directory Lightweight Directory Service (AD-LDS) which is not useful for PC logins but is otherwise a solid LDAP directory.

  • There are lots of other LDAP directory products available, including OpenLDAP (free/open source), OID (Oracle) and many others.

  • AD is interesting in a number of ways:

    • It is tightly integrated with the Windows operating system.

    • Users in a corporate environment normally sign into their PC with an AD ID/password, rather than a local ID/password that exist only on the PC.

    • There are tools in AD (group policy objects) used to manage security policies on PCs and in relation to users.

    • AD is very scalable, supporting real time and fault tolerant replication of directory contents across hundreds of directory servers, which Microsoft calls domain controllers.

IDENTITY AND ACCESS MANAGEMENT:

  • Whereas a directory is a place where you store information about users, and retrieve it when needed (for example, to identify users logging into systems/applications, authenticate them and check what they are authorized to access), an identity and access management (IAM) system is used to automate the business processes of populating and managing the contents of the directory.

  • An example use case of an IAM system is to monitor an HR system, detect new hires, moves and terminations and automatically create, modify or delete login accounts and identity attributes in one or more directories in response.

  • Another example use case of an IAM system is to expose a web portal where users can request changes to their own or other users' access rights or identity information. Such requests may be subject to validation and authorization before they are written to one or more integrated directories.

  • Additional uses cases for IAM systems include password synchronization between multiple systems and applications, self-service password reset or unlock when users have login problems, periodic review and cleanup of stale access rights (such as login accounts and group memberships), maintenance of org-chart relationships (linking managers to subordinates), application of policies, such as segregation of duties (people who have this group membership should not also have that group membership) plus all sorts of reports and analytics.

  • IAM systems typically integrate with many systems. This includes HR applications or other "systems of record," directories such as AD or OpenLDAP, local accounts on systems such as Unix/Linux, Oracle, MSSQL, etc., access rights in applications ranging from on-premises things like SAP or Oracle EBS to cloud-hosted apps such as Salesforce.com, Concur, etc. and much more. The value proposition of an IAM system can be thought of as due to the product of the processes automated times the systems integrated.

IDENTITY AND ACCESS MANAGEMENT:

The bottom line is that directories are where you store data about people and other objects, IAM systems are how you manage that data at scale with good efficiency and controls.

Incidentally, there is a nice collection of terminology definitions that relate to IAM here (archived)

user_24412650

Another major problem in the inconsistent use of the term "Identity." In most IAM solutions, the Identity is the single identifier that all other accounts in other systems will then be associated. You have one Identity, and multiple accounts in multiple systems. That is where the system of record, authoritative source or golden source comes into play, and it is rarely AD. HR is usually the system of record utilized for this Identity as it should never change, regardless of your employment status, location, etc. True, your primary AD credentials are used to get you on the network, give you your email and many other resources. But many of us have more than one AD account, and there are too many scenarios where that unique identifier you are counting on in AD will actually change. SID isn't usually a functional choice in most IAM solutions, so other attributes are chosen, and those can and will change; usually when you've invested way too much using this attribute and you suddenly realize your solid, brick built house is now a potential house of cards.

Unfortunately, even MS uses Identity too flippantly, especially in the Azure space. They talk about Identity when they should be using the term "account." In these MS discussions, you will have multiple Identities. That doesn't work in the IAM world. Until we decided Identity is that single sourced reference to you, we used to call it your "belly button account," meaning you hopefully only have one belly button, and that "belly button account" is the one that all the other accounts you have are tied to. Think of a master key in a heavily distributed, relational database. It's how you link all the different instances of access across multiple systems back to an individual, including multiple AD accounts.

user_83098230
Related