All-In-One Identity Management and Cloud Security

For years and years,Microsoft has been recommending AGDLP as the way to manage your file system permissions.  User and computer accounts are members of global groups which are members of domain local groups that give resource permissions.  This is, to put it mildly, the old and busted way of doing things (OBWDT for short).

And here is why: try telling me who has access to that file.  You know, a user who is nested within a nested group that nobody knows who manages.  In fact, you don't even know the last time that group was updated.

So, how do you solve this?  True role based access control (RBAC for short).

If you are doing RBAC correctly, you have a metadirectory that is assigning roles dynamically or statically to your users.  These roles are granted access to resources.  Your RBAC-based file share manager will continuously  inventory and monitor for new shared folders and follow a workflow to give the appropriate roles access.

Here's the other side of the coin.  A user knows about a shared file or folder and wants access; I saw this use case on an IAM board on LinkedIn today in fact.  How does that user request access?  Does he or she have any idea what group or groups manage access?  No.

Why not give an easy self service format for the end user to request access to the folder that is routed to the correct approvers?  Without the end user needing to know a single thing about AGDLP or other technical nonsense.  RBAR (rights based approval routing) to the rescue.  This workflow knows who can approve and how long that user can have access.  A top secret folder being accessed by a contractor, give them access for 3 days, no longer.

Just because Microsoft (MSFT) recommends using an old and busted technique (OBWDT) like AGDLP shouldn't stop you from looking into RBAC to properly solve your file system permissions issues.  Schedule a demo ASAP.

What is identity management?  That is a loaded question.  Ask a dozen identity management professionals and you will get a dozen different answers. 

I define it as such:

Identity is who you are, what you can do and what you can see.  Identity management is what the organization knows about you, what applications and resources you can use, and how you access them.

I put this question to all of our customer facing staff, figuring that they are talking about this topic all day long from dozens of different perspectives.  Two things immediately became clear, all of their definitions revolved around our solution AND that they all mentioned the word person (or people).

I am new at The Dot Net Factory, so EmpowerID's greatness hasn't yet biased my definition but it does give a real warning as you, the IT and identity professional, veer down the path of managing identities.  Don't let the vendor define identity management for you.  Think about what your needs are, what your business problems are, and get a solution that is right for you.

Which brings us to the second point: people.  I always joke that a person is a person until they are hired, then they become an employee; once IT gets ahold of them they become a user; and then IT never deprovisions them and they are a user for life.  Kind of dehumanizing.

But you cannot manage a user's identity.  Because each person is multiple users.  They are a user of Salesforce.com, a user of Exchange, a user of quickbooks, et cetera.  A user has a department, a title, and a role; but each application they use, gives them a different role, has different identity information about them.  Somehow you have to take all of those users and recompile them into a person. 

I can't even say employee because you also care about the identities of your partners, customers, alumni, etc.  Do not forget the person in identity management.

This is why you get a dozen disparate answers from a dozen different professionals.  Because they have a dozen different definitions of a person and a dozen ways to compile that person.

Back to vendor bias, EmpowerID does it with a metadirectory and an RBAC and ABAC hybrid model.  Our metadirectory creates a person object that is a compilation of all user accounts (even multiple AD accounts), allowing you to understand a person's identity and apply dynamic roles for access and authorization.  Schedule a demo (once you have your own IdM definition! ).

Or take a look at our whitepaper on the RBAC / ABAC hybrid approach to enterprise authorization (what you can do based on who you are!).

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).

Not all applications are created equal. For some corporate apps, everyone should be able to access them.  Some should be restricted to certain users, groups and roles.  Some even more sensitive applications should be restricted to certain users, groups and roles and have a higher standard of authentication.  We call this adaptive authentication.

Let's use examples:

• Corporate holiday calendar:  everyone should be able to access this just using their corporate logon.
• Salesforce.com app:  only users in the sales group or role should be able to access this.
• Financials ERP app:  only users in the finance group or role should be able to access this but you want two factor authentication and/or identity proofing before letting them in.

Single sign-on can and should accomplish all of these tasks.  For number one, it's a simple federation with the app (scenario # 3 in the whitepaper "Top 5 Federated Single Sign-on Scenarios").  For number two, it's scenario 1, corporate login to cloud application, pretty simple to do with SAML or OAuth.

Number 3 is the fun one that requires adaptive authentication for single sign-on.

This diagram shows the workflow used to accomplish this.  You set a level of application security in the SSO systems inventory.  Any application that is over level 5, for example, needs to have two factor authentication integrated into the login.  The user is logging in to the ERP financials system, the workflow checks that they have access and then before allowing authentication, it executes a second factor authentication (something you have to have, not just something you know like a password).

This second factor can be an SMS message, an RSA security token, and even be identity proofing from within the directory (what was your previous job title, what was your hire date, etc.).  Single sign-on is there to make your users' lives easier, but it should also improve security.

Schedule a demonstration of how EmpowerID can accomplish adaptive authentication or read the whitepaper on the "Top 5 Federated Single Sign-on Scenarios" now.

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.

The traditional model for self service password reset drives me crazy.  The user gets asked questions to prove they are who they say they are.  And the system just resets their password.  Easy, right?  Secure, wrong.

Here is the issue, I can guess most of the answers to your questions by looking at your facebook timeline and the pictures on your cubicle wall.  Your first car, your daughter's name, your eye color, and so on.  That just isn't as secure as it should be.

What you need is two factor authentication with your self service password reset.  The first factor is the questions, in other words "what you know."  The second factor is something you have, whether it's a pager or mobile phone or a keyfob device.  With proper two factor authentication, someone is not only going to have to steal your user's memories but their phone also!

This still doesn't get you everywhere you need.  It is also important to have complexity requirements, either to match or exceed your Active Directory domain policy.  My own personal preference, make the complexity pertain to password length rather than crazy characters.  It's harder to hack a 72 character sentence than P@ssw0rd.  And it's easier to remember the sentence.

Having a proper password synchronization and SSO tool also improves your password security.  If users have a dozen passwords to remember they are going to make them easy to hack.  They are going to forget them a lot and use easy to hack questions.  Make life easier on your users and your security will increase...counter intuitive but true.

Get a second factor in your self-service password reset, it's easy and secure for your users.  Click below for a demonstration of how simple this can be.

Identity management runs on workflow, but not the traditional workflow of "who approves what".   Identity management workflow is really business process automation for identities. You, as IT, know what systems and resource access should happen if a new employee is hired, or fired, or moves departments.  The workflow is the process that makes that happen.

And you should not have to code anything.  Let me repeat, you should not have to code anything.

Let's walk through an example.  Bob is hired into sales as a Senior Account Manager.  The workflow sees a new employee in your HRIS, determines location, department, title and any other pertinent information.  Roles are assigned and the workflow automatically kicks off a process for provisioning into Active Directory, Exchange and Lync.  Everyone gets those.

Seeing that the user's department is sales, the workflow provisions a Salesforce.com account and since the user's location is Des Moines, the user is given an account for the badge system and access to the networked printer.

This is where it gets cool using rights based approval routing.  The user's title is Senior Account Manager...the senior means something around here.  Because of that title, the user is given extra privileges to send out mass emails using a 3rd party tool.  But because of the cost of said mass emails, you actually want to get the CFO's approval so a subworkflow is kicked off to have the CFO approve this right.

The identity management workflows can do even cooler things in the world of authentication.  Because the user is in sales and has access to account information, the SSO workflow forces two factor authentication the first time the user logs in from a new computer and forces password reset re-enrollment quarterly.

These, and many other, workflows can be created using a drag and drop workflow designer in EmpowerID.  Of course, you could try to create them yourselves using some other IAM softwares and an army of developers, but why?  With 370+ out of the box workflows and the ability to create and customize many more based on your requirements, make identity management workflow do your work with EmpowerID.

Schedule a demo and never have to approve another IdM workflow again.

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!

The cloud is like the wild west right now.  Cloud applications are roaming the plains like gunslingers in a Spaghetti Western.  That's a crazy analogy but the point is that all the hard work IT has done over the last decade to corral identities within your network has been rendered useless in the cloud.

Everything you know about your user is rendered useless when they go out and create an account in the cloud.  A perfectly useful account for them to do their job but you in IT have no control over how they use it.  Or know what they're doing.  You have no idea what the user's cloud identity is: how they access it, what their account is, or if they should have access to it.

You need to understand their cloud identity.  The best way to get a user to buy in to IT knowing about their cloud life is to offer them something.  Cloud single sign-on is the best incentive to get users buy-in.  Think about it, if you want to know that weird little obscure account they are using, tell them you'll help them sign on more easily with their network account.

So, how do you integrate cloud identity into your network identity?  Workflow, beautiful role based workflow.  Let's take the biggest and most common example: salesforce.com.  In this example, you have 4 basic types of users who use salesforce: sales and service, user and manager.  Two departments, two roles in each.

If you have an IdM platform provisioning users and giving them roles (if you don't, please call us!), just assign a workflow that provisions the cloud applications like salesforce.  You know the user's role, so you can assign different permissions in salesforce to a sales manager v. a service user.

Once you've created the cloud account (in this case salesforce), you know the password, you have it linked to the user's network account.  You give the user single sign on to the cloud application.  Most cloud applications use some sort of standard authentication: SAML, WS-Trust, WS-Federation, and OAuth.  Now, between the provisioning, the SSO, and the role based access, you know what the user is doing in your audit and you have controlled the wild west.

Of course, in this scenario you have also controlled what they do on network.  And you might have dozens of cloud applications that you now control.  Identity in the cloud is NOT different than identity on the network, you just need a way to manage both together.