I had been demonstrating how to manage the creation and automation of AD security groups and distribution lists for months before I realized that I had no idea what the differences were between the three types of Active Directory groups: universal groups (UG), global groups (GG), and domain local groups (DLG). I asked around, poked around the web and found that nobody is really 100% clear on it. Or at least the ones that would talk to me.
With a little work I dug out enough info for this cheatsheet on Active Directory groups:
- Universal Group: can contain users and groups (global and universal) from any domain in the forest. Universal groups do not care about trust. Universal groups can be a member of domain local groups or other universal groups but NOT global groups.
- Global Group: can contain users, computers and groups from same domain but NOT universal groups. Can be a member of global groups of the same domain, domain local groups or universal groups of any domain in the forest or trusted domains.
- Domain Local Group: Can contain users, computers, global groups and universal groups from any domain in the forest and any trusted domain, and domain local groups frm the same domain. Can be a member of any domain local group in the same domain.
The short answer is that domain local groups are the only groups that can have members from outside the forest. And use global groups if you have trust, universal groups if you don't care about trust.
Disclaimer: this might still be wrong. But nobody has disputed it yet; thankfully, with good comments, I can always edit the blog post if I have something wrong.
Right after Exchange 2010 was released, I was quoted in Network World stating that none of our GroupID customers planned to move to it immediately. I immediately received two responses, one customer contacted me on Twitter and said he was very soon. And one guy stated in the comments that the obvious reason I said that was that we didn't support Exchange 2010 yet.
And then there was silence.
About two weeks ago, we had a spate of customers and prospects start making noises about migrating. It wasn't overwhelming but enough to shake my belief that nobody was going to move to Exchange 2010. I decided to move past the anecdotal evidence I love so much and will now ask people in a not-so-scientific but better-than-nothing poll.
In exchange for participating in the poll, we are offering a free copy of our whitepaper, "Unlock the Power of Active Directory Groups." This whitepaper provides information on best practices for managing AD groups (security and distribution). To encourage participation, it is an anonymous poll.
In the first night of the poll's existence, I've found some surprising and not so surprising data. The larger companies are describing the process from difficult to "I'm never doing that again" when upgrading to 2007. And nobody has yet answered that they are on 2010. This might be explained by the average time after release to deploy a new version is 15 months.
Again, this is not a significant sample size (...must...get...more...blog...readers...) yet but we will keep working to find more information on important topics like this. Take the poll and add to the fun.
In the last few years many organizations have been through at least one round of layoffs, reduction in force or organizational restructuring.
Going through that process is painful and challenging in a host of ways, including the effects on the morale of the remaining employees. Organizations are running increasingly lean and in most cases the workload is growing heavier. Nearly everyone is being asked to do more work with fewer resources.
The best practices in HR suggest that the way to get everyone back to work with maximum productivity is to communicate at each step of the way, to be clear about the path forward, and to move on.
But that moving on part can be hard when your employees are constantly being reminded of colleagues they no longer have. How are they being reminded? Here are a couple of places to look.
- Directories and the GAL (Global Address List) - If Joe Smith was laid off in the Portland office, is he still listed in Outlook?
- Email groups - When your employees left the organization did they also leave all the distribution groups that they were a part of?
- Project/security groups - If you have former employees that still are listed as members of these groups, not only are you reminding the remainder of the team that they are no longer there to help with the work, but you may be exposing yourself to some significant security or regulatory risks.
The way to solve this is to make sure that you are properly (and preferably automatically) provisioning and de-provisioning your employees. This is usually a cooperative process between HR and IT making sure that the changes made in the HRIS are also promptly reflected in their systems, which is usually Active Directory.
Change is seldom easy, but constant reminders of the way things used to be can be a huge road block to employee morale and productivity that's easy to fix.
I hesitate to call a QBDL by its other name, QBDG, because it isn't a group. In fact of all of the letters in the acronym "Q" is really the pertinent one. The reason is that a Query Based Distribution List isn't a list or a group, it is a query and only a query.
When you create a QBDL, you write a query. This query is stored in msExchDynamicDLFilter and msExchQueryFilter attributes in Active Directory. When Joe User sends an email to this list, Exchange resolves and expands the query into a list of users and sends the email. I am writing this sentence in red because warning flags should be going up right now deep in your administrator heart. What happens when somebody responds to that email? What happens when a mailstorm breaks out? What if that query returns a large number of users? That's the problem with QBDL's in a nutshell, it requires access to a Global Catalog server and a poorly designed or frequently used query for the DL could severely impact Exchange and Active Directory performance.
There are also limitations to the queries for end users. If you receive an email to QBDL@sampleco.com, you have no way to expand it in Outlook to see who the members are. Users are used to that capability; they tend to want to know who they are emailing most of the time. In today's security conscious environment, you don't want users responding to or sending emails to an unknown audience.
So you ask, what is a dynamic Active Directory group if it isn't a QBDL? It's a group that is created by a third party software (yes, Imanami sells one such software) that uses a query designer to actually create an Active Directory group behind the scenes. And there is the difference, it creates an actual group object and not just a query. This dynamic group can be a security group or a distribution group; heck, it can be a mail enabled security group.
The advantage to having a dynamic security group is that you can use it to grant access and permissions and always know it is accurate. A great example might be that everybody in sales needs to see the folder with the latest sales presentations, that query is simple (department=sales), and presto there is an always accurate dynamic AD group that grants that permission. If you need something more granular, only sales directors should see the sales reports folder, the query adds a step (department=sales, title=director) and that group grants that permission. Many security groups can be defined this easily, reducing a great burden on the help desk.
Going back to QBDL's, does having a dynamic AD distribution group solve the problems above? Yes, they do. Since an actual group is created, end users can expand it to see who the members are. The group is created most likely during an off-peak hour and the query is run only once no matter how many times it is mailed to so there is very minimal performance hit on the network.
There is one advantage to a QBDL, the query is run in realtime so if somebody changes departments at 2:00PM, then an email at 2:01PM will reflect that change. But overall, the advantages to having dynamic Active Directory groups as opposed to a bunch of network-destroying queries are numerous.
One of the primary responsibilities for IT is to actively help their organization's users stay productive. If the overall workload required to do that is 100 units of help, you can bet that your organization's current capacity is somewhat south of that number, most likely less than half. If your organization is like most, you are measured on how well you help these users stay productive. It's a thankless job.
That's not to say it's not possible to satisfy all of your end users. Quite to the contrary, it is very possible if you have the correct tools (or an endless pool of trained help desk workers) in place. The three main tools that your ITdepartment will use are automation, delegation, and lastly help desk (helpdeskation?). The question is how much you can get out of each of these tools.
The easiest and usually first point of attack is automation. Since I work at an Active Directory software provider, I will focus my comments on that particular system. You can do a lot with automation of Active Directory. The first step is AD provisioning; either through scripting or off the shelf software, automate new AD user creation. If the authorititative source (usually your HRIS) shows a new employee not in AD, simply create a new user. With this same process you can continually synchronize all of the pertinent employee data such as department, title, phone number, etc as the user moves around the organization. With an accurate Active Directory, you can then dynamically manage distribution lists and security groups. Many estimates are that this will solve 50% of your help desk calls.
The next step is delegation. Web based Active Directory management gives end users the ability to manage their own directory information and groups. Again, this can be a home grown solution or off the shelf. The main warning I will give is that if you delegate control to end users, you need a solid foundation of workflows and notifications to control what they can and cannot do. Field level security on attributes and workflow on group creation and membership changes are essential. Between this and resetting password, you can lop another 40% of your help desk calls away.
These two steps free up an amazing amount of time for your help desk which is usually staffed by a fairly well trained and expensive resource. Giving them that 90% of "help units" back allows your organization to be proactive in helping end users.
I admit to being a big fan of Centrify so I was especially pleased to find this "chalktalk" they were giving on the same day that I was researching Group Based Access Control (GBAC). The premise of my research was that Role Based Access Control (RBAC) is too limiting, trying to fit a square user into a round role -- there is only so much granularity you can get with roles. Active Directory security groups are a better way to manage access and permissions in my opinion.
Centrify's solution is for managing access to UNIX, Linux and OS X through Active Directory and specifically leveraging Active Directory groups. Wow, that is right up our alley! We manage AD groups dynamically, creating dynamic security groups and distribution lists. We also give very granular control over end user AD self service so that you can trust your users to manage their own AD groups. It seems like a perfect fit, certainly more automated than managing these groups through Active Directory Users and Computers (ADUC).
Having these two solutions together makes for a seamless and simple way to manage UNIX, LINUX, and OS X but I'm still struggling to find a company that does GBAC for Windows users. I must be missing something; I know that Windows provides the capability natively with GPOs but every single other major component of the AD infrastructure has a 3rd party software that takes Windows functionality and makes it simpler and more robust, why not GBAC? There are a million RBAC solutions, even some Attribute Based Access Control vendors but no 3rd party Group Based Access Control softwares.
I'm still in the beginning stages of my research but somehow we are going to make it easier for organizations to manage access through AD groups. It just makes too much sense not to.
We all know that the economy has cut IT staffing to the bone. While there seems to be some rebounding from the lows of last year, organizations are still running very lean.
Healthcare IT organizations are in a particularly difficult place. At the same time that their IT staff has been cut to meet shrinking budgets they are under ever increasing pressure to take on and execute more projects. Not only are they being tasked with implementing Electronic Health Records (EHR) with still undefined "meaningful use" but they may also be responsible for Computerized Physician Order Entry (CPOE), image management and new quality systems. At the same time they are being required to support the deluge of new hardware, software and devices showing up in the network without any warning.
And the news gets worse. Dr. David Blumenthal, the National Coordinator for Health IT sees the need for 50,000 healthcare IT workers, but no one seems to know where these folks are going to come from.
So, what is a forward thinking healthcare IT executive to do?
One answer is to do everything in your power to make sure that each minute of your current staff's time is able to be dedicated to those projects which are going to add value to your organization. That means that everything else that can be automated or delegated should be looked at.
Where to start? Here are a few places that we have seen organizations recoup time and resources.
- Employee provisioning and de-provisioning - Provision your users into Active Directory, create email accounts and give them the correct roles and responsibilities. Not only does it eliminate manual tasks, but it improves security and compliance.
- Employee Self Service - By delegating certain updating responsibilities to your users you actually can increase accuracy while decreasing the amount of time that is spent to get it. Password reset and employees updating Active Directory with personal information are perfect examples!
- Database and Directory Synchronization - The healthcare setting has so many applications across so many systems that the more you can get them to talk to each other the less time your help desk will spend on it. That means more time your users can spend caring for patients or running the business that allows for improved patient care.
The best way to prepare for the upcoming challenges is to figure out even more ways to do more with fewer resources. Automatically!
In many organizations, Active Directory provisioning consists of a series of manual processes and emails and help desk calls that ultimately finish with an employee having a network login and hopefully an Exchange email account. It is ripe with potential for errors and just not a good use of limited resources.
But then the problem gets exacerbated in the next step. Giving a person an offer letter moves them from person to employee. Provisioning an Active Directory account turns that employee into a user. To move them from user to "productive user" requires access to resources, something that often requires group membership.
That's why I find the traditional definition of provision and deprovision to be so limiting. What organization wants a user with an AD user account only? So that user can sit at their desk and type their password and possibly browse the web (assuming that right isn't controlled by a security group)?
Provisioning really needs to extend to the next logical step, AD security groups and Exchange distribution lists; thes group memberships should be automated. If someone is in the Albuquerque office, they should be in the groups associated with that office. If they are in marketing, they should be on the correct DLs and security groups. Automatically.
This gives the whole middle part to a user's life in between provisioning & deprovisioning. Access to resources and information. And it's very easy to accomplish.
Unfortunately, that's the point that Imanami's involvement ends currently. We provision/deprovision users into Active Directory and Exchange. And then we automate all of those users' group memberships. Other, more expensive, IdM suites do solve another problem...getting users provisioned into other systems. Think about keycard systems, parking passes, security certificates and anything else that the user needs. This is fundamental to provisioning and something of which we are keenly aware.
But the first step has to be to get rid of the "Rube Goldberg" approach, ditch the manual processes, and automate the AD provisioning to the point of productive user immediately.
One of the tricks of Active Directory management is the fine balance between usability for end users and performance. A great example of this is the usability of security groups. Active Directory security groups are an excellent tool for granting access to network resources. You could be tempted to load up a user with security group membership for every possible resource they might need to use.
But this idea would come with side effects. Token bloat is a fairly serious issue affecting login performance. The token includes the SIDs of all AD security group memberships for a user, including nested groups. The token can hold a maximum of approximately 1,015 SIDs and as the number of security group memberships approaches that number, it can lead to significantly increased login times as AD tries to resolve all of those permissions.
And it is fairly easy to accumulate security group memberships. Remember that users will always tell IT what permissions they need but very rarely tell IT when they no longer need that access. I like to picture security group memberships as keys. On your first day on the job, you are given 5 keys for things you need to do your job. But then you get promoted and get 3 more keys. Move offices and get 2 more keys. Pretty soon you look like a New York super with a 10 pound keychain weighing down your belt.
So how do you solve this? Diligence? Don't answer the phone when someone takes forever to log in? Ruthlessly delete security groups and memberships? That might work until the first time the CFO needs to get to that file that he only uses once per year.
But there are some best practices for security group management:
- Do not allow groups that have less than 5 members (or some other arbitrary number). This keeps the number of insignificant groups down.
- Dynamically manage security group membership. If a user moves from the Pensacola office to Tallahassee, you shouldn't have to do anything manually; instead have group membership controlled by a dynamic query that will see that change in AD or some other accurate data source and automatically take the user out of the old group and put them in the new one.
- Expire and delete old unused groups. Since it is very difficult to track when security groups are being used on a large scale, have a process where group owners have to renew their groups every 6 months. If the group is still being used, renew it. If it is not, let it expire. Never go straight to a deleted state as you may need to renew the group and the permissions will be lost if deleted.
Reducing group glut and old group memberships will significantly reduce the effects of token bloat for all but your most access-hungry users. Using groups wisely will give you all the benefits of group management without the bloating and discomfort.
SharePoint is becoming ever more popular, especially with the upcoming release of SharePoint 2010. SharePoint is an excellent tool for communication but we're getting more and more questions about how to use Active Directory's group structure to manage access. Large enterprises with thousands of users need a simpler way to manage SharePoint access.
Some tips that we find useful both internally and from discussions with our customers are:
- Grant SharePoint access via groups rather than users.
- Use AD groups rather than SharePoint groups to increase flexibility and ease of management.
- Dynamically manage as many of the groups as possible; use a tool to write queries that keep membership accurate (not QBDL obviously).
- Name the Active Directory groups with descriptive names and always fill in the description for users to know what the group is for.
- Allow SharePoint resource owners to manage the membership in their own groups through self-service.
- Allow self-service for users to join and leave groups. It is important though that if you open up web-based group management, you must ensure that you have security controls in place.
- have workflow set up if you want to allow for group subscription; this allows the group owner to approve or deny a request to join the security group.
- Mail enable the AD groups to allow for easier communication about that SharePoint resource.
One factor that is becoming more prevalent is auditing access to SharePoint resources. As more and more business critical information is posted to SharePoint, a strong Active Directory auditing solution will help monitor group membership and ensure that only the correct users have access to these resources.
Managing groups is always easier than managing users if you have the appropriate tools and processes in place to ensure they are accurate.
In a recent survey, we found that managing groups in Active Directory is painful or very painful for 25% of respondents and only 6% found it to be no problem at all. It's pretty obvious why this is considered painful, 81% of all organizations have a manual process for managing Active Directory groups.
And despite 81% managing AD with their best and brightest, there are still a lot of errors. Of the survey respondents, 42% report that they have users accessing information by being in an Active Directory security groups that they shouldn't be and 44% of the AD admins themselves report being in Exchange distribution lists that they shouldn't be. And, these are AD admins!
Think about internal turnover, people changing from one job to another by getting promoted, reorganized, or just moving locations. Every time a user needs access to something, they call the help desk but when was the last time a user called and said, "hey I don't need access to this folder anymore, can you revoke it?" That's right, users don't do that.
And that's where the problem comes in. 21% of respondents found managing Active Directory more boring than filling out expense reports and 19% found it more boring than taking out the garbage. With that kind of competition, no wonder the manual processes fail.
For more details and background from this survey, "Managing Active Directory", download the free file from our website.
Identity management has been defined by wikipedia (great source, I know, but bear with me) as:
Identity management ... is a broad administrative area that deals with identifying individuals in a system (such as a country, a network or an organization) and controlling the access to the resources in that system by placing restrictions on the established identities.
And that's where identity and access management (IAM) seems to live, managing individuals or users. Provision/deprovision the user. Add a role to the user. Give this user access to this or that resource.
The problem is there are a lot of users. Applying permissions to each user is unwieldy and an overwhelmingly expensive task. Roles try to solve that. In a role-based identity world, User A and User B are both salespeople in the New Orleans branch so they get the permissions that a New Orleans sales rep should have. But then again, not every employee needs the same things and including/excluding users from certain roles and keeping track of that is again a very overwhelming and expensive task.
That's where groupcentric identity management can come into play. Most organizations already have the Active Directory group structure in place. You use it for domain admins, SharePoint admins, Exchange admins, and of course Exchange distribution lists. But if you think of each unique user as belonging to a variety of groups such as department, location, title, project teams, etc, it become simple to create Active Directory groups that have the requisite permissions and add users to the groups that fit.
If you have a strong group management process in place, you can manage permissions in a more flexible manner than roles or user-centric identity management ever could. Just put users into the appropriate groups based on what you know about them from AD, HRIS, and/or that spreadsheet that the CIO's assistant keeps and give permissions to those groups.