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.
Imanami has been
chosen as a SINET 16 Innovator and asked to present at the annual SINET Showcase. Each year, a select group of technology companies that can improve efficiency and security at government agencies are asked to present and demonstrate their solutions. Imanami's GroupID will help
solve identity management security problems from group-based access control to robust identity stores to the age old provisioining & deprovisioning problem.
"We are confident that by raising awareness of Imanami and other finalists, they will have a direct and significant impact on meeting the most pressing technology needs of Federal Government and private industry, and ultimately, the protection of our nation's critical infrastructures and command and control systems," said Robert Rodriguez, Chairman and Managing Principal of SINET.
Robert Haaverson, CEO of Imanami, adds, "With government agencies and corporations being asked to do more with less, managing the most fundamental level of security, what your employees have access to, by automating Active Directory group membership, is critical to your business."
With this exciting opportunity comes great responsibility. SINET knows that we solve employee access issues and deprovisioning, but our own research shows that over 40% of employees have access to resources through outdated group memberships. We need every corporation and government agency in the world to know how to fix that. Talk to us, let us demonstrate GroupID, and fix these security flaws in your business.
I was recently talking to a customer about the best practice for deprovisioning a terminated employee in Active Directory. Delete or disable? Microsoft doesn't give the clearest direction on this but common sense does.
The case for deleting an account is that, BOOM, no more access. No ifs ands or buts, if there is no account it cannot do anything. The case for disabling an account is that all of the SIDs are still attached to the account and you can bring it back and get the same access right away. Sort of like how your mother never threw out egg cartons; you never know when you might need them.
And then the reason for MSFT's lack of direction came into play. Individual needs of the customer. This particular customer is a public school system and they often lay off an employee and have to re-hire them the next month or semester. They need that account back (and the teacher probably needs the egg cartons for some art project).
So disabling the AD account is key, the best way to go about it. But, like Mom with the egg cartons, you don't want to be a hoarder. Keeping all of those disabled accounts in your production user OU is just bad form. And a very slight, but possible, security risk.
So, we recommend moving disabled AD accounts to a non-production OU as part of your deprovisioning/disabling process. With GroupID Synchronize, it's simple, just insert a powertool into the job that moves the account to another OU as soon as the account is disabled. Place the reverse in your "bring back to the fold" provisioning/enabling job and you have satisfied all of your requirements.
It's then easy to manage the "disabled user" OU; if an account has been there too long, delete it. You get to decide the policy based on your individual needs.
I see the term Active Directory management tools used everywhere from provisioning to SSO to reporting to auditing. I see it used for managing users, groups, GPOs, and everything in between. It seems to be a broad term meaning software that fills in the holes that Microsoft left in AD.
It also seems that "tools" are perceived as less valuable than "solutions". Think about it, a "solution" solves a problem. Solutions are big and cost a lot of money. But Active Directory has created an interesting dynamic; it is a great product that left a lot of holes for independent software vendors to fill. Active Directory is a great solution that needs a bunch of different tools for it to reach its full potential.
Don't get me wrong, Imanami's GroupID is a "solution"; from beginning to end, we solve a real world business problem (getting users active with the ability to work securely). But we also made GroupID into modules so that you can buy just what you need...I think that makes our modules Active Directory management tools. That seems to be the fairest way to present it to the market, a solution as a bunch of tools that can be purchased independently.
GroupID's tools (making up the magnificent solution) are:
- Synchronize: Provision and depprovision users in AD from any source(s). Synchronize attributes to and from any source(s). Basically, keeping all your identity data happy and accurate.
- Automate: Based on having happy, accurate identity data, automate the membership in all of your distribution and security groups. As important as putting users in the correct AD groups is taking them out of the incorrect ones.
- Self-Service: What you can't automate, delegate. If something in AD can't be synchronized, have the user update it. If AD and any other data source can't definitively say Joe needs to be in a group, have a group owner manage it (with workflow if needed). Also, AD history and group lifecycle to make it even more exciting!
- Password Center: The most common AD problem (and cause of over a third of help desk calls) is the forgotten password. Give users the ability to reset their own forgotten password without bugging IT.
- Reports: Probably the biggest hole in AD is the inability to know what the heck is going on with all the objects in it. This free "tool" tells you everything you need to know. And it's free.
Imanami is just one example of the tools needed to make Active Directory run properly. But if any of these are interesting to you, let us know and we can help you "solve" your business and IT problems with them.
When Microsoft first released Forefront Identity Manager (FIM), they described an alarming statistic:
On average, every new user needs to be added to 16 directories upon hire; upon fire, the average user is only taken out of 9 directories.
Wow. I don't know the source of that statistic, but if it's true then the average user is still floating around in 7 directories after leaving a company (I assume they mean directories and databases). To be fair, these might be completely benign data repositories like Active Directory, the badge sytem, payroll, who knows what. Or they could be important :) .
I just know that I want ex-users completely deprovisioned to the point they cannot do anything on my network. I can't imagine that MSFT meant they were inactive users on those directories because our own Active Directory research shows something else alarming: it takes an average of 9 days for organizations to deprovision a user from Active Directory after termination.
9 days of access, what could a bad guy do with that? Steal all your CRM data? Book a flight to Paraquay? Steal source code? Plant a virus? Prank call customers from within your phone system? This is a big deal.
The obvious answer is to create an automated provisioning and deprovisioning process. GroupID Synchronize allows you to create bi-directional provisioning and deprovisioning jobs with almost any database or directory as a source or destination. GroupID does not use a meta-directory, instead writing directly to the source DB/directory.
Find the authoritative source (usually HR) and go from there. Once you identify all the systems where a user needs to have accounts, simply provision them using GroupID. During their hopefully long and productive career, use GroupID to synchronize changes in their identity (department, shoe size, title, etc). Once they are terminated, use the reverse of the provisioing jobs and deprovision them from the destinations. You can even daisychain these jobs to be sure that all data is passed along (for example, HR doesn't have an email address until provisioned in AD/Exchange).
If you fear that there might be ex-users sitting in 7 directories on your network, schedule a demo of GroupID or download a free 30 day trial. And, don't take 9 days to do it!
