Identity management/MIM - application authentication - clarification?
With identity management, something like Microsoft Identity Manager, does this mean that if you have an application on-premise, and you have A.) an Active Directory, and B.) an ADLDS also on-premise, that the application can authenticate a user from both A and B by connecting to an identity management server via LDAP instead?
Is there a meta-verse where their login is created and password is sync'd from ADLDS or AD, and it the application authenticates against the meta-verse/MIM database?
Is there a meta-verse where their login is created and password is sync'd from ADLDS or AD, and it the application authenticates against the meta-verse/MIM database?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I meant to ask a follow-up here, if you don't mind responding again...
But, with an IDM like MIM, say you have self service Active Directory password reset scenario setup.
If one of the steps to resetting a password for a user is to text their mobile phone and/or e-mail their personal E-mail address, would you need their mobile phone # and personal e-mail inside an attribute on their AD user object?
Or would the MIM allow the reset tool to lookup that info in the IDM (i'm assuming SQL back-end database) to carry out?
Because I'm hearing here that Synchronization is the meat of an IDM, but, what good would syncing HR data be that in, say, an encrypted database, to a non-encrypted AD database where everyone by default has read-all access to that AD environment?
But, with an IDM like MIM, say you have self service Active Directory password reset scenario setup.
If one of the steps to resetting a password for a user is to text their mobile phone and/or e-mail their personal E-mail address, would you need their mobile phone # and personal e-mail inside an attribute on their AD user object?
Or would the MIM allow the reset tool to lookup that info in the IDM (i'm assuming SQL back-end database) to carry out?
Because I'm hearing here that Synchronization is the meat of an IDM, but, what good would syncing HR data be that in, say, an encrypted database, to a non-encrypted AD database where everyone by default has read-all access to that AD environment?
Self service password reset by phone would depend on the features available by the solution you use. I haven't worked with MIM's solution for SSPR, but it does have its own database that could store that. Or it could pull it from AD data. Most third party apps use their own SQL back end to store security questions and stuff like that.
As for the encrypted/unencrypted question, you can customize things so specific information is not synced between applications. So not everything in an HR database will get copied to AD. Things like hire date, compensation, and other private info can remain untouched by the sync engine, while non private data like manager names, given names, and office numbers can sync up so you only have to change them in one place, rather than having to go through all applications making updates.
The primary benefit is reduced workload, but it does have to be properly managed.
As for the encrypted/unencrypted question, you can customize things so specific information is not synced between applications. So not everything in an HR database will get copied to AD. Things like hire date, compensation, and other private info can remain untouched by the sync engine, while non private data like manager names, given names, and office numbers can sync up so you only have to change them in one place, rather than having to go through all applications making updates.
The primary benefit is reduced workload, but it does have to be properly managed.
ASKER
From what I was told, as you mentioned O365, is that you could create an account in Azure AD, and then sync it with an existing on-prem AD account? That's not possible, right? I've never heard of that, but someone told me that it's possible.
My understanding is you can only create the account in on-prem AD, and let it sync up to O365. There's no Azure AD or O365 to On-prem syncing, only the other way around -- unless you're utilizing the Password write-back feature...?