Active Directory password reset by role

Posted by Edward Killeen on Tue, Oct 30, 2012

active directory password reset by roleAs 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.

Schedule a demo of Role based password reset

Tags: Role Based Access Control (RBAC), Active Directory, Password management

Replacing Active Directory Users & Computers

Posted by Edward Killeen on Mon, Oct 15, 2012

replacing active directory users and computersDelegate 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.

Click me

Tags: Active Directory, Group Management, User provisioning, Identity and Access Management (IAM)

Active Directory group management and RBAC

Posted by Edward Killeen on Wed, Oct 03, 2012

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 group managementActive 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!

Download whitepaper Active Directory Management

Schedule a demo AD Group Management

Tags: Active Directory, Group Management

Active Directory self service as an authoritative source

Posted by Edward Killeen on Wed, Jul 18, 2012

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.

Active Directory Self ServiceProviding 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.

Click me

Tags: Active Directory, User provisioning, Identity and Access Management (IAM)

Active Directory self service: back to the basics

Posted by Edward Killeen on Mon, Jun 25, 2012

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.

active directory self serviceThe 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.

Click me

Tags: Active Directory, Identity and Access Management (IAM)

Active Directory Synchronization: a good simple start

Posted by Edward Killeen on Thu, Jun 21, 2012

active directory synchronizationWhen 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.

Click me

Tags: Active Directory, Identity and Access Management (IAM)

Replace ADUC: put an end to super-privileged accounts!

Posted by Edward Killeen on Mon, Jun 04, 2012

highly privileged ADUC accountI 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).

Click me

Tags: Role Based Access Control (RBAC), Active Directory, Identity and Access Management (IAM)

Does Identity Management start with Active Directory?

Posted by Edward Killeen on Wed, May 30, 2012

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.

Active Directory in the middle of nowhereThe 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.

Click me

Tags: Active Directory, Identity and Access Management (IAM)

Role based provisioning for AD and beyond

Posted by Edward Killeen on Tue, May 29, 2012

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.

shoe displayConsider 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.

RBAC and ABAC hybrid

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.

Click me

Tags: Role Based Access Control (RBAC), Active Directory, User provisioning

Top 3 uses for dynamic security groups in Active Directory

Posted by Edward Killeen on Thu, May 24, 2012

dynamic security groupDynamic 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!

 

Click me

Tags: Active Directory, Group Management