All-In-One Identity Management and Cloud Security

We get involved in some very cool intricate discussions on identity management; delving into federation, RBAC, provisioning workflows, all the really fun stuff.  But sometimes you have to step back and realize that there is some blocking and tackling needed.  You need Active Directory self service.

End users are an incredible source for identity information and permissions management.  What you can't automate, delegate.  And this is very true.

The problem is that Active Directory houses some very sensitive information and many extremely important business processes are keyed off of it.  As such, you can't let an end user change their title or direct reports or gain access to the shared folder that houses the 10Q documents.  So, when delegating, keep RBAR in mind.

What's RBAR you say?  Rights based approval routing.  The idea that you take your roles and assign what can and cannot be changed in AD based on who is asking.  If it's the title attribute and the requester is the VP of HR, you let the change happen.  If it's the mobile phone number and it's the user requesting it, make the change.  If it's the telephone number and the user's manager asking, route that approval over to IT for an official OK.

It's really that easy.  It takes IT out of the process unless it's something that they need to know and/or approve.  It gives control to the business owner who should know what needs to happen.  And it maintains the integrity of Active Directory.

This RBAR concept also applies to Active Directory group management.  Different groups have different levels of security.  Anybody should be able to join the "book of the month club" group; but an approval should be needed to join the "Top Secret book binding project" group.  CEO approval should be needed to join the "10Q analyst call" group and HR approval should be needed to leave the "Employees on probation" group.  RBAR it.

What happens when you flip the tables and offer file share access via self service?  Nothing different, apply the RBAR concept to requesting access to a resource.  Don't just rely on the outdated AGDLP method to manage access, utilize roles and RBAR.

I could go on and on but our whitepaper already did that, discussing how to delegate permissions into AD without giving permission to AD.  Take a look.

When you start work in the morning, you authenticate against Active Directory; when you start thinking about identity and access management, you start thinking about Active Directory.  Active Directory is at the heart of it all but is often oddly neglected.

Identity and access management is a lot of things: user provisioning, user deprovisioning, single sign-on, role based access to systems and resources and my favorite the whitepages.  Seriously, the whitepages.  The whole point is to enable employees to do their jobs and one of the lacking things in many organizations is the ability to find co-workers.

Active Directory provides the mechanism for this but often times is neglected.  Take the "Mike Smith example".  In an organization of over 10 people it is statistically probable that there is at least one Mike Smith; in any organization over 100 people it is a statistical certainty that there are at least three Mike Smiths.  This is advanced math, please trust me.

There are a few ways to tell these Mike Smith Dopplegangers apart...department, title, location, middle initial, picture, et cetera.  And the global address list exposes these.  But what if these attributes are not in Active Directory, as they very often are not.  You have to synchronize Active Directory with your HRIS or other authoritative source.  And do it often because department, title and location change.

Easier said than done, you say?  Well, no, it is as easy to do as say.  Synchronizing Active Directory is one of the most elemental and easy accomplishments in identity management.  Most, if not all, IAM platforms eat this stuff for breakfast.  EmpowerID is configured to do it in the first day of implementation, if not the first morning.

As mentioned above, IAM encompasses a lot of great functionality, but let's start with Active Directory.  Make it accurate and the rest of your day just got easier.  Give us 30 minutes to demonstrate this building block of IdM and we think you'll go out and solve your own "Mike Smith" problem.

I had a customer years ago who couldn't keep Active Directory identity information accurate, so they gave everyone access to ADUC.  You know, so that the users could update their own address, etc.  This company went bankrupt; that's what happened when you give fully privileged ADUC access to more than the handful that should have it, you go bankrupt.

Don't go bankrupt, it's bad for the economy.

To solve this age-old problem, you need a way to manage users and computers in Active Directory with appropriate permission sets. 

• Let domain admins have their way with AD, but actually get yourself a useful audit trail
• Let helpdesk users manage group memberships and identity information without the ability to accidentally delete an OU (yes, I've seen that)
• Let end users manage their own identity information with some sense of workflow

Having an Active Directory self service solution enables you to do all of this.  But you need something a little more robust than a web page with built-in permissions to change attributes and group membership. 

This ADUC replacement should be integrated with your overall role based access control (RBAC) policy.  You shouldn't have to delegate new permissions, you know who should be able to do what.  The same system that manages access to systems and resources can provide the rules on who can change what in AD.

And with rights-based approval routing (RBAR), you can simply state the protected actions, give a role level or attribute level of who can approve and turn it loose.  Something like deleting an OU?  Can only happen with three domain admins agreeing.  Something like changing my mobile phone number?  Easy, you can do it, no questions asked.  Change a title?  Only if a director or above in HR says it's OK.

And get yourself a safety net outside of your AD backup.  Have a meta-directory that catalogs every single change EVER and it's pretty easy to restore changes or deletions without losing the old permissions.

Take a look at how EmpowerID can easily replace ADUC and add a ton more value.  And it can help you from going bankrupt (claim not verified by anyone but it's a great way to tie the blog post together).

Active Directory does seem to be at the heart of everything.  Thanks to the persistence of Windows computers, authenticating against AD is the simplest and easiest way to get in to the network.  It's a pretty strong ecosystem to start your identity.

The trouble is that your users' identities stretch far and wide nowadays.  There are tons of internal systems that they need access to, scads of databases holding pertinent pieces of their identities, even multiple AD accounts belonging to the same person.  You have data governance being handled by AD security groups without an easy way of knowing who has what access.  You have cloud applications that need to know who your user is and what they can do.

Active Directory is the most essential identity repository while somehow being peripheral.  It's weird.  I have spent most of my career in identity management (dating back to Isocor/Critical Path) thinking that metadirectories are too complicated to be truly useful.  But EmpowerID's metadirectory has changed my mind. 

EmpowerID is so simple to manage thanks to the workflow designer that it might even be easier to manage than Active Directory itself.  And it provides all of the IAM functionality that you need, right in one central place.  Built on the principles of easy to manage workflow and integrated RBAC, you populate all of your users' identity information in once place.  Authentication to internal and cloud apps happens right there.  Group management and data governance are combined and centralized even if you have multiple ADs.  And user provisioning into any system becomes easy.

Active Directory is an essential piece to Identity Management but it is very incomplete without a strong IAM suite.  You know, like EmpowerID.  Click the link below and we can demonstrate how IAM can build off of AD but not be restricted by it.

User account provisioning isn't really rocket science.  You want users to be able to do their job from day 1.  What you don't want to do is just provision a user account in Active Directory and call it a day.

Remember this stat: a user is only 58% productive without the proper permissions according to the National Institute of Standards & Technology.  So, when provisioning a user, give them more than their AD account; provision that user to every system that they are supposed to be in.  Don't lose 42% of a user's productivity.

Consider what you know about a user from your HRIS: name, department, title, location, shoe size; all the relevant identity information for you to decide their most basic roles (you can determine more granular roles as you learn more about them).  From these basic roles, you can provision them into the correct systems.

To take that identity information and turn it into role based provisioning, you need workflow.  Workflow isn't just approval routing, it is the ability to set a business process within your provisioning and access control.  For example, the first box in this workflow is what location your user is in...depending on location, your user is provisioned into the proper card access system and put into the correct security group for printer access. 

Once that workflow is complete, every user returns to the next decision point based on department.  A user is provisioned and is given access to Salesforce.com if in sales or service, to Quickbooks if in finance, etc.  Of course, you can be more granular but people stop reading blogs if you get into too much detail!

Now the third workflow kicks in based on a piece of identity information not usually associated with roles: shoe size.  Each user/employee is given a pair of shoes for the company's annual Race for a Good Cause.  This is where the ability to have a hybrid of RBAC and ABAC comes in handy.  You want your supply chain software to provision a different color shoe based on departmental role, but also give the correct size based on an AD attribute.  Simple, a hybrid approach to RBAC and ABAC applies to provisioning as well.

Now your user has an AD account and, thanks to role based provisioning, has been placed in the correct systems and security groups, is operating at 100% productivity on day 1, and most importantly wearing the correct color shoes.

Click below to schedule a demonstration of how to manage role based user provisioning and extend it into an ongoing RBAC process.

Dynamic security groups in Active Directory are extremely important, not hard to do and inexplicably don't come out of the box from Microsoft.  Why are they extremely important?  To answer a question with a question, when was the last time a user came to you and asked to have some old permissions revoked?

They changed jobs and immediately demanded all the new permissions they now need and neglected to say, "hey, I was in operations, maybe you should take away my permissions to X, Y and Z."  Even if you are using roles, you are undoubtedly also using AD security groups.  So, manage them dynamically.

So, it's a given that you need to manage membership of AD groups dynamically, and if you follow that link above, you can see how easy it is, but what all do we use these AD groups for?

1. File and Folder access:  Windows is built on using AD groups for files and folders.  You want to manage these permissions efficiently to avoid token bloat but still give access to all the right data.  Most software systems give you an either/or situation....either manage membership dynamically or manage the permissions.  EmpowerID File Share Manager merges these ideas and allows you to dynamically manage membership and permissions.  Together.
2. Application access: this is a tough one because Windows does not support this in any way outside of its own integrated applications.  But these dynamic groups can and should be the method to access applications.  The key to this working is to have an authentication process which can recognize security group membership and roles, you know, something like the EmpowerID metadirectory.  SharePoint is an interesting example of this; SharePoint handles permissions based on AD groups but gives no way to manage the groups easily or well.  Make them dynamic and you have this solved.
3. Group Policy Objects (GPO): there is a subset of GPOs which apply well to groups.  Actions like applying desktop or IE settings by department.  You sure want to be sure to have the correct members in the departmental groups if you are doing this.

In all of these situations, if you are managing files/folders, applications or GPOs by AD security group, you run the risk of having out of date security groups if you are trying to manage them manually. 

A simple to use group management tool allows you to manage the membership dynamically; there are a few choices out there but the key to your choice is how extensible is it.  Do you want to just manage the membership?  Or add key components like what files/folders permissions does the group have and how do you incorporate provisioning and single sign-on to the applications based on group membership?

If you see the need for these dynamic security groups, let us show you a demonstration of the full value of managing the groups and what they can do!