All-In-One Identity Management and Cloud Security

A pride of lions. A gaggle of geese. A mob of wombats. An Active Directory Security group.  

It’s natural to group things and your users are no exception. Many organizations have more groups than users, a user can be a member of hundreds of groups. We’re talking AD security groups, distribution groups, LDAP groups, SharePoint group, and roles.

We know that 81% of organizations manage these group memberships manually, expending an amazing amount of resources to keep them accurate. If they keep them accurate.

There is something that can be done about it…automate and delegate. Automate the group memberships with dynamic groups. Delegate to group owners the ability to manage their own memberships. Delegate to users the ability to join groups. And put workflow controls in place to keep it organized.

EmpowerID has two methods to manage Active Directory groups dynamically, by roles and by set groups.  The benefit of each is that they can be used across a wide variety of identity and access governance functions: from provisioning to SSO to access control.  And both methods can be used to manage Active Directory security groups dynamically.

Even using the more advanced method of managing permissions with roles, you will still need AD groups, both security and distribution.  And EmpowerID gives you both of these methods to keep your group membership accurate, dynamically. 

This first video explores how to use the roles that are pervasive throughout EmpowerID's Identity Management suite to keep group membership dynamically updated.

In addition to the role based method, set groups can be created in EmpowerID that will manage the group's membership.  As with roles, these set groups have additional functionality in all aspects of IAM from authorization to authentication.

Group management is only a part of EmpowerID's full Identity and Access Management capabilities. EmpowerID's robust IAM platform is built modularly, so you can solve the business problem of today while laying the foundation for future IAM capabilities. 

Take a look at the dynamic group videos and schedule a demo. Save money while improving security and productivity.

Identity and Access Management is all about the authoritative system.  The identity source of truth.  Most often it is the HR system, but for some very important information it is your users.

What you can't automate, you delegate.  And this is especially true for user identity information such as mobile phone, home address, or other personal identity information.  Your end users know this information, you and HR probably don't.

The solution is to give them Active Directory self service.  Delegate the ability to update pertinent identity information in AD but only the pertinent information.  You will need role based access control to determine what the end user can and cannot update.  Let them view title but not edit it.  Allow them to update their office phone but put an approval workflow in place for their manager or the help desk to confirm it. 

But this information belongs in more places than Active Directory.  If your user updates her home address, that information should flow to your payroll application.  If mobile phone is updated, that should flow to your emergency contact list.  Identity is a lot more far reaching than Active Directory, but AD is the place that your users understand; it's the global address list, they see it all the time.

Some information goes the other way.  Your user gets a promotion and the new title is put into the HR system, that information needs to flow to Active Directory.  That same promotion prompts the user to need access to the customer portal and that information flows directly to that portal, provisioning an account if necessary.

Having a metadirectory functioning in a hub and spoke model allows you to configure these attribute flows easily and efficiently.  The EmpowerID metadirectory gives a visual attribute flow to determine which identity store is authoritative and which is a recipient.  You can also have a "first wins" scenario, taking the last change regardless of which system is the originator.

The metadirectory "hub" keeps a record of all changes, allowing you to audit which system recorded the change, when where and how.  You can roll back changes, apply additional workflow actions to any change, and audit these changes periodically.

The idea of adding a workflow to an automated change might seem counterintuitive but the idea is to have identity controls in place for applications that don't necessarily have controls.  Active Directory is a great example.  If you have ADUC access, you have ADUC access.  You want to have role based access where users can manage some attributes, managers can manage more, the help desk even more, and the admins to have more access.

Having a check and balance on each of those powers is important.  Think about this, the users with the most privilege (domain admins and senior executives) also have the most ability to bypass your security.  If you ran an audit on users with passwords set to never expire, the list would most likely be littered with names from those two sets.  And, they are the users you need the most secure.

So if a change comes from ADUC into the metadirectory on a particularly important attribute (say, relating to password policy), put a control in place.  Have another domain admin approve it even though it was an automated feed.  Same thing for title, kick off a workflow when someone's title change from HR contains VP or "Chief".  This is simple checks and balances just like we all learned in the 5th grade.

The metadirectory gives you an easily managed model to flow identity information to the correct identity stores.  It allows you to automate AND delegate.  And, it enables auditing to a level that native application access won't.

As George Orwell said, "All animals are equal but some animals are more equal than others."  How does this apply to resetting passwords?  Everyone needs passwords reset, but some need a little extra security around their password resetting.

Let's take the scourge of the help desk, active directory password reset.  Everybody has seen the statistics of how expensive it is to have your help desk take these calls, somehow verify that the user is who they say they are and reset the user's AD password.  On average, $35 per call.

The obvious solution is self service AD password reset.  Give the users an easy link to reset their password when it is either forgotten or they are locked out.  They will answer a pre-configured number of knowledge based questions (eye color, favorite pasta noodle, etc); once answered, the software trusts who they are and lets them reset their password.

The issue with this is that some animals are more equal than others.  Do you really want the CFO's password to be compromised because someone read his facebook profile and figured out his eye color and the astounding amount of fusilli that he eats?

The way to solve this is role based Active Directory password reset.  Based on the user's role in your RBAC system, you will require a higher level of authentication before allowing them to reset their password.  Maybe it's just more questions.  Or it could be two factor authentication via SMS.  Or it could be identity proofing.  Or it could require approval by a help desk employee.  The point is, based on a user's role, you can make this password reset more secure.

I have always found it distressing that the higher level of security needed for a user's role, the more likely they are to be violating some basic security rules.  For example, the CFO has a bit of influence in a company; if he hates changing his password, he can talk people into allowing his account to have a "never change" policy.  Same thing for domain admins.

Role based password management should do just the opposite, it should make these more sensitive roles more secure.  Two factor authentication is not that intrusive, just a quick SMS message that your user plugs into a form during password reset.  Identity proofing is even easier, it again is something the user knows like their monthly mortgage payment.  Security doesn't have to be painful.

And by managing security based on role, you don't have to assign this stricter level of authentication if all that role does is punch in and out of the timeclock application.  You still save that $35 per call but can also protect your network with more dexterity.

And here's the best part.  This isn't limited to Active Directory.  If you are managing all of your passwords through EmpowerID, you can reset all of your passwords together or separately.  You can reset your salesforce.com password separate from AD.  And you can do all of this based on your user's role.

EmpowerID password manager utilizes roles and resets passwords, one of the benefits of having a purpose-built integrated IAM platform.  Schedule a demo and see how you can keep your CFO's account more secure.

Delegate and Automate.  The first two words of IT.  It is especially true with respect to managing Active Directory.  There are a lot of authoritative sources of identity information that Active Directory needs and not one of them is your help desk employees.

And that's one of the main issues with managing AD, it often falls into the help desks' hands.  They get an email from HR saying to create some users.  They get requests to add users to AD security groups.  They might get an email that Jane Doe got promoted to a new job in Operations.  And for all of these changes, they have to have access to Active Directory Users & Computers (ADUC).

Once you have access to ADUC, you have access to ADUC.  By that I mean that the help desk user can not only create a new user but delete an OU.  Not only can they add a member to a security group but they can make themselves a domain admin or member of the executive security group.  It just isn't that safe or secure.

So you want to be able to delegate and automate your Active Directory management.  Have end users have only the access they need to make changes.  Give them a self service portal that follows pretty strong workflow rules, giving field level security to changes on their profile or their users.  Give them the ability to request membership in some groups and not others.  Allow them to manage the membership of a group that they own.

By using rights based approval routing, anything that user is allowed to do is done instantly.  Anything that needs approval from another user is routed for their approval.  Anything that they shouldn't even see (the distribution group of users on steps of discipline for example) never appears before them.

EmpowerID allows this self service management with a level of granularity and security and role based access control that makes ADUC completely irrelevant.  Grant access only to make changes in AD that the user is allowed to.

But that doesn't cover everything.  Automation is your other big step.  Creating a user still shouldn't be done manually.  You probably have an authoritative source like HR that can be inventoried to see if a new employee exists or if an existing employee has changed.  Once the new user is inventoried, EmpowerID will provision the user into Active Directory or make changes to their job title or any other change.

These new or changed users will have a specific dynamic role and will be provisioned into the correct systems, given access to the right resources and be a productive member of the corporation immediately.

With the right combination of delegation and automation, you don't need to have ADUC access for any user.  You can manage all of the AD objects and attributes without the "everything" access that comes with native tools like ADUC.

Take a look at our whitepaper on replacing ADUC and schedule a demonstration of how we can help you delegate and automate.

I am a strong proponent of RBAC -- managing roles effectively does an awful lot more for your enterprise than Active Directory groups.  However, you still need AD groups to be managed.  And, in my opinion, no IT admin should ever have to manage these groups.  What you can't automate then delegate.

Active Directory groups are essential for fileshare permissions, for email communications, a few GPOs, and just plain useful for some application permissions.  You can use them for SharePoint, though I recommend you utilize roles for that as well.  Either way, you still need to manage them without taking up your entire day adding and removing members from AD groups.

To keep from investing a full time person managing AD group membership, you need to do two things: 1) create dynamically maintained groups and 2) offer self service to your users to manage their groups.

Dynamic AD groups are exactly what they sound like.  You write a simple (or complex) query that can read attributes in Active Directory or your HRIS or some database with useful identity information.  Your group memberships dynamically change whenever any of this identity information changes. 

You will need dynamic groups for security groups and distribution groups.  Don't fall for the Exchange QBDL trap...you cannot manage permissions with those.  An application like EmpowerID Group Manager has an exceedingly simple interface to manage these dynamic groups for both security groups and DLs.

The only complication is GIGO, you need to ensure that your identity stores are accurate.  Having a metadirectory constantly inventorying these data stores will ensure accurate information on your users and keep the dynamic AD groups accurate.

Now for the fun part...delegating group management to your users.  Obviously, do not do this without solid workflow controls in place.  You will have group owners managing membership in their groups, this is usually a pretty solid practice.  If you trust them to own the group, you can trust them to manage the group membership.

But the piece you want to add to this equation is group membership attestation.  Either for regulatory or token bloat reasons, make the group owner attest to the membership and existence of this group periodically (bi-yearly for example).  If they don't need it, de-activate the group.  If the member should no longer be in the group, remove them.

There are also groups that your users know they want to join.  Give them a self service portal for joining or leaving groups.  Put workflow on it so that approvals are needed either from rules or approvals.  Make some groups unjoinable (such as the 10K report team) and some wide open (like the book club).  For the rest, have the owner approve membership or allow anyone within a certain division of the company to join it but disallow others.

Which brings us to separation of duties.  Make sure that separation of duties are enforced with AD groups the same way they are with roles.  If your users is on the investment banking side of the house, they should not be able to join any groups in retail banking.  If they are in the invoice approval group, they cannot be in the sign a check group.  These SOD rules have to be built into Active Directory group management the same way they are in your RBAC rules.

It is pretty clear that AD group management is important.  It is also a vital part of your IAM strategy.  If the need is to knock off one piece of ROI-producing identity management quickly, consider group management.  Just think of all of your helpdesk time spent keeping those groups accurate.  Take that money saved and move on to RBAC managing ALL access and permissions!

There are some things that only your users know.  So why not make them the authoritative source for that identity information?  Some examples would be mobile phone number, home phone number, emergency contact information, and oddball information like shoe size.

Providing Active Directory self service gives you a good place to store this data.  Most of these items have attributes in AD and you can easily synchronize that information from AD to your HRIS or emergency notification system.  You can even then start making dynamic Active  Directory groups based on the information.

But you don't want to open ADUC to just anyone so you need a role based Active Directory user interface for self service.  The reason for role based is you need to have security built in to the self service web page so that I don't go and change my colleague's title.  You'll need to have rights based security allowing a manager to change some fields for their employees and the employees to have access to change other fields.

You then want rights based approval routing to make sure that somebody is there to approve any changes that need approval, whether via email or an approvals dashboard.

We have a whole whitepaper on how to replace ADUC, take a look.

But then there's another issue.  What if Active Directory isn't the place to store the information?  For example, you have union employees who need to update their union membership with HR every once in a while.  You don't want that information flowing through AD to get to your HRIS.

We solve that with a metadirectory.  The metadirectory has pretty flexible attribute flow rules so you can create a self service page using our forms designer, have it update the metadirectory (again, using rights based approval routing) which flows directly to HR without AD being in the middle.  To use technical jargon, presto bammo, you have self service updates without IT having to be involved.

This is probably EmpowerID's most basic and simplest use case, with almost the entirety of this functionality able to be installed, configured and deployed in two hours.  Give us a shout for a demonstration and we'll have you up and running in no time, delivering Active Directory self service for user and group management.

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.