Active Directory provisioning is a vague abstract term. Is a user provisioned once they have an AD account? Once they have an Exchange mailbox? Once they are in a few security groups? Or once they can do their job?
I posit that it is once they can do their job. And that's where the rub is, the National Institute of Standards & Technology concluded that a user is only 58% productive without his or her permissions. So, next time you "provision" a user, consider when/where you stop. Do you assign them to security groups or roles? Do these groups or roles encompass everything this user needs to do his or her job?
What about when the inevitable change occurs? When a user moves from operations to marketing? Do you get rid of old permissions (reducing the possibility of overentitlement) and add the new permissions (reducing the possibility of underentitlement). You have to be able to automate that, get the new identity information from HRIS or some other authoritative source and dynamically manage their group or role membership.
No business will survive with 58% productivity every time a user changes or starts a position. Think about internal and external turnover in your environment and think of how your business will prosper with that lost 42% productivity just by managing permissions and completing the user provisioning process.
You run an IT department. No matter if it is big or small, you have to have a help desk. Your help desk is the public face of IT, the people that the rest of the company knows. So they call them. For everything.
You know the problem with this, help desks are expensive to be tasked with such difficult issues as saying, "is your computer plugged in?". Yet, that's what you get. No way to avoid it.
But, what you can avoid is, "I need to get all emails that are sent to the marketing department!" or "I can't access the folder for the operations department!" or "I can't print to the printer down the hall!" or "I changed my cell phone number, can you publish it for me?".
All of these things (and more) are controlled by Active Directory and can all be fixed with Active Directory self service. You know, the things that end users know about themselves and need to have in AD.
A good AD self service solution will allow end users to:
- Change some of their identity attributes
- Join and leave certain distribution lists
- Join and leave certain security groups
- Create distribution lists or security groups
- NOT ALLOW all of this to get out of control
It will get out of control unless you put workflows and other restrictions in place. Someone wants to change their title, no way without HR approval. Someone wants to leave the book club DL, of course, no problem. Someone wants to join the Annual Report 10K group, never. Someone wants to create a group for their top secret project, of course, once an IT admin approves it. Things like that.
Why is this so important? Because end users and their jobs change constantly. On average, there is 20% internal and 8% external turnover per year. 1 in 5 users change jobs, 1 in 12 leave the company. That doesn't even account for the constant change in projects. Each one of those users calls the help desk if you don't have AD self service. They call the help desk at an average cost of $35 per call!
Take a look at a simple ROI calculator for Active Directory self service and see if you can answer the question why you need it right now!
In attribute based access control, access to resources is based on the attributes of a user, not from the resource owner specifically granting access to that user. The user proves their claim based on attributes associated with them rather than having joined a group and/or a role.
A great example is that printer down the hall from you. You really don't want to have to grant access to everyone on your floor or even manage an Active Directory security group of everyone who should be able to print on it. You know that everyone on the third floor of the Peoria office should have access to print on it.
But somehow that printer needs to know that you work on the third floor of the Peoria office. Enter Active Directory. It knows this stuff, your office location is a central important piece of identity information. So you just create a dynamic security group that places everyone on the 3rd floor of the Peoria office as a member. A new employee...automatically a member. Of course, AD doesn't come with dynamic security groups out of the box, but Imanami makes it pretty easy.
There are times when AD doesn't have the correct identity information. For example, only sales reps above quota should be allowed to print to that printer. Just add a database condition to that query that says location = Peoria AND %toquota (from your ERP) > 100. Boom, attribute based access control, without your end user having to prove that claim in any way. Just be a member of the correct dynamic AD security group!
And, that poor rep sitting in the Peoria office not making quota? Handwritten proposals!
Nobody's Active Directory is perfect. And by "perfect" I mean with accurate identity information. Users are an ever-changing group, they switch jobs, last names, phone numbers, cubicles, departments, and projects. The users know this information but, guess what, IT doesn't always.
So Active Directory gets lonely and out of date. Eventually, nobody's identity information is in there and it's only used for authentication.
The good news is that HR knows this information. If they don't, your problem is much bigger than identity management! So, what do you do?
Synchronize.
Synchronize user information from your HRIS over to Active Directory. Every night, every hour, every minute, as often as you need, check your HRIS for changes and bring them over to AD. New job title, not a problem: job-title ===> title. New city, no problem: city ===> l.
And for the stuff that AD knows that HR doesn't? Bi-directionally synchronize that stuff right back at them. Email, shoe size, mobile phone number? Let AD be authoritative!
Here's a little video sneak-peek at how GroupID Synchronize does it.
Want to see more? How about scheduling a personalized demo? Or checking out our pre-recorded demos? Let us know you're interested and you'll get both.
Active Directory literally sits in the middle of everything. As the King of IT Infrastructure, it holds the ceremonial middle spot in any server rack. Well, maybe I'm mis-using literally. But figuratively? You bet it sits in the middle of everything.
We have carved out a niche as THE software solution for managing Active Directory groups. Some days I think it would be nice to not be in a "niche" but then I realize I'm mis-using that term also. Because this "niche" is huge, a veritable canyon of a market. Because everyone uses Active Directory groups.
The top use is, of course, email. If you had to type out every email address of the people in marketing when you wanted to send something to them, you would give up on email.
The top access related use for Active Directory groups is granting access to files and folders. It is considered best practice to never grant access to an individual user even if that is the only user that needs access. For this reason, over 93% of organizations use AD groups to grant access to the file system.
The number that we expect to grow when we re-run this survey in the Spring is access to systems. Currently about 78% of organizations grant access to systems based on group membership. I think this will go up based on cloud adoption. As I outlined in the post on "Using AD groups for cloud identity management," more cloud single sign on vendors are using on premise AD groups to determine who should have access to cloud apps.
As confusing as Group Policy Objects are and can be, they are at their most valuable when applying them to AD groups. This way you can get more granular than just "everybody in that OU" should be able to VPN to the network. 72% of organizations use AD groups for GPOs.
The next number is surprisingly low. When we last ran the survey, only 52% of organizations use AD groups for SharePoint access. That number is now up to over 70%, primarily due to the increased adoption of SharePoint 2010. My belief is that it will grow even higher by Spring.
Take a look a the summary of our research report and see how your organization's use of AD groups stacks up. Then take a look at a demo when you realize just how important AD group accuracy is to you.
While reading Gartner’s research paper titled, “Identity in SharePoint 2010” by Kevin Kampman, I was struck by one particular phrase that is at the heart of the AD or SharePoint group debate: “visibility is not provided into domain group memberships; SharePoint administrators cannot directly examine the members of an AD group, although it is possible to examine group membership with SharePoint.”
This mirrors our own research into the matter and is supported by anecdotal evidence from many customers. See, we want them to use AD groups because we can help them with the membership accuracy. But if their SharePoint users can’t see that accurate membership, they still won’t use them.
Eventually, we got one customer to give us the exact use case they wanted to solve this problem. They wanted a site owner within SharePoint to be able to pop up a window with every Active Directory group that was being used to grant permissions to that site. From that window, they wanted the site owner to be able to pick a group and either view or manage memberships within it. They would then close that window and still be sitting there in the SharePoint admin site.
So we did it. Here’s how:
From the Permission Tools section of Site Actions, the user will click on a “Self Service Permission” tab within the ribbon. This whole ribbon can be customized and this tab can be called something more intuitive like “manage domain groups.”
Then a pop up window will appear listing these domain AD groups that define permissions within this SharePoint site.
Once the user clicks “Edit Membership” the GroupID Self Service page appears to manage or view that membership.
Interestingly enough, all of this work is within SharePoint and utilizes its APIs to figure out which of the groups are domain groups. Once there, it is simple to access GroupID Self Service for that particular group. If the site owner is indeed one of the AD group’s owners, he or she can update the group membership. If they are not the owner, they can simply view the membership and determine if this is the group they want to have permissions within their site.
This method should help ease the internal struggle between AD and SharePoint groups. In fact, if done right, you can eliminate SharePoint groups entirely, allowing a quick method to create groups from that same ribbon pane or have all SharePoint site owners be additional owners for AD groups. A lot of possibilities exist that are more productive than the “let’s just let our SharePoint groups get out of date” method that is so often used.
I recently watched a great video on cloud federation by Coreblox and Ping Identity. You know the problem they're trying to solve, your users are using applications in the cloud and your access and authorization solutions are stuck on premise. Ping Identity solves that beautifully.
Here's the gist: an AD user is added to an Active Directory group which PingFederate recognizes and provisions them to the cloud application; take the user out of the AD group and that user is de-provisioned from the cloud application. As long as the user has an account on the cloud app, PingFederate grants them single sign-on privileges to access the account. Easy peasy.
Except in the real world. Don't get me wrong, their part is easy, we have a mutual customer who assured me of that. What isn't easy in the real world is keeping that Active Directory group accurate. If you're going to use Active Directory groups for cloud identity management, you want to be sure that the membership is ALWAYS accurate.
Most product demos concerning Active Directory toss this in offhandedly, saying something like "just update the group membership." Do you realize how many groups you have? And you're supposed to go into ADUC and just, you know, update the group membership for each one? Say you have 5 cloud applications with 3 to 4 levels of access for each, meaning you have 15-20 groups to update with potentially thousands of members.
Managing that manually is a mess. Most projects that start with the simple premise of "just update the group membership" end up having 100% accurate membership on day 1 and then deteriorating in membership quality as time moves on until it's pretty much useless (see SharePoint).
The thing is most cloud apps (Salesforce, Webex, box.net, ADP) have an identity profile associated with them. Salesforce is the sales team or the service team. Webex is sales and service. Box.net is everybody working remotely. ADP is finance. Why not dynamically manage that AD group membership?
You need managerial access to Workday? Well since your job title is director or above and your department is Human Resources, you are automatically in that group. You need account rep privileges to Salesforce? Since you are in sales and your title is account executive I and you are not in the employees on probation group, you are automatically in the Salesforce AE group.
This needs to just happen or you'll never get to cloud federation. As long as the AD group structure exists and is so widely utilized, you cannot afford to let group memberships become outdated. Ping Identity uses them and I can only assume that Okta and Symplified do as well.
But Active Directory doesn't come with dynamic groups. That's why GroupID exists, to make dynamic security groups for you. If these groups are managed dynamically, you get past that point of "just update the group membership." You don't have to because it already is updated.
Get your users into the cloud by putting them in the correct Active Directory groups.
They say a picture is worth a thousand words. So behold this novella:
Imanami's GroupID won the Best Windows Product award at the recent Windows Connections conference in Las Vegas. Our HQ lobby is filled with awards and plaques and other achievements but I find this one a little more satisfying than most.
Why? Because the judges were Sean Deuby and Amy Eisenberg, two incredibly knowledgable and astute industry veterans. They both already knew about our GroupID suite and the Active Directory problems that it solves. We had spoken many times about it.
But, this judging review focused on something we had never covered before. The usability of group management when the group owner(s) know everything there is to know about their group. Having a historical audit trail of changes to groups, having the ability to expire/renew groups, and seeing how often a distribution group is even used takes AD group management to another level.
Gone are the days when the admin has to make huge decisions with absolutely no knowledge about the business use of a group. Now, the group owner can make these decisions, armed with all of the knowledge necessary to properly attest to the group's usefulness. Yep, AD group attestation for the masses!
We won the Best Windows Product award not only because GroupID can save an IT organization money and time, but because the business can leverage the investment that IT has put into the Active Directory group structure to run their business better.
Now that's a picture worth reading.
In the world of Active Directory, groups are binary: they exist or they don't. Other AD objects can be tombstoned, but with groups, they become useless once tombstoned since all of the ACLs and memberships are lost. And AD doesn't give you the ability to expire and renew them while keeping all of this vital information.
So, what do you do? Delete them and hope that nobody complains. If a user complains, you painstakingly recreate the group from scratch. Ouch.
Thankfully, Microsoft's various holes in their infrastructure give an opportunity for enterprising software vendors to fix issues like this. Here's what we think should happen:
I'll try to convey this in one amazing run-on sentence. As an administrator, you set a policy on how long a group should live; x days before it is set to expire, the group owner (or owners) receive a notification with a link to renew the group; if they don't want the group, they let it expire, if they do want it, they renew it; if the group expires, they can still renew it (possibly because they found they lost some access or emails were bouncing), through that same link; but after another preset number of days, the group will be deleted; but, here's the catch, the idea isn't to actually delete it but to disable it in a way that only the admin can bring it back. And in any of these situations, the cycle will repeat itself.
Now why not just keep all your groups active and alive instead of bugging your group owners. Three reasons:
- Security (these groups give access to resources or information)
- Token bloat (too many groups can lead to login failures or worse)
- Confusion in the global address list (hmm, which group for sales should I send this email to?)
This seems so absolutely straight forward that I'm surprised you haven't called us for a demo of GroupID already. We can show you how to solve your issue with a bloated Active Directory and expire and renew your way to improved security.
The average organization has just under 20% annual internal turnover. This means that 1 in 5 employees will change jobs per year. At the same time, external turnover is approximately 5%, meaning 1 in 20 employees will leave the organization. That, my friend, is a lot of change.
But it is nothing compared to the White House. Imagine that on top of average turnover, there will be 100% turnover every 4 or 8 years. ONE HUNDRED PERCENT. How do you keep Active Directory groups accurate in that extreme environment?
You absolutely need to make sure that on day one (especially if you only have 4 years to change the world), your employees have access to printers, SharePoint, top secret files, and distribution lists. And you need these groups create automatically, making sure that the last team's users don't have access via these groups.
Below is a short demonstration of how to use GroupID Automate to automagically create and update these groups based on changes in AD or any other data source(s). If the Executive Office of the President can survive the change from the Whig Party to the Green Party in 17 clicks, imagine what it can do for your less extreme environment!
I like the example because the whig party actually ceased to exist in the mid-1850s, about when most manual processes to manage AD groups were devised. Please, automate this process so your organization doesn't go the way of the Whigs.
