When we designed GroupID to work with Exchange 2010, we didn't want to simply "support" Exchange 2010, we wanted to be sure that we worked with it. The reason is that Exchange 2010 has introduced a small subset of GroupID's Active Directory group management features into OWA and we were determined to complement these features so that our product would recognize those settings from OWA.
The two that they added of most note are multiple group owners of distribution lists (not security groups) and security levels on opting in and out of groups. We quickly realized that since we have a large installed base of AD self service customers that will eventually migrate to Exchange 2010, we wanted to be sure that anything that their users do in OWA would be respected by GroupID.
If additional group owners are set in OWA, then GroupID will automatically recognize them. If a change is made that requires workflow in GroupID Self Service, then the additional owners will be notified and have the option to take action on that workflow. The additional owners have the same level of rights as the primary owner in GroupID.
The same is true for setting a security level for opting in and out of groups. If the group owner sets a group as private in Exchange 2010, nobody can opt in to the group in GroupID Self Service. If it is set so that a workflow needs to be approved and somebody tries to join the group in GroupID, then a workflow is kicked off.
We find it important to complement the continued improvement of Exchange and keep innovating ahead of it with key features like security group expiration, dynamic AD groups and enforcable naming conventions. By definition, all of our customers work with Active Directory and Exchange and playing nicely helps our customers.
Imanami's GroupID has a simple yet effective method for AD group self service. We allow the group owner or Admin four choices for group security:
- Private: closed membership
- Semi-private: owner must approve membership request
- Semi-public: notify owner of new membership
- Public: open membership
When you open group membership for self service, the owner(s) assign the security level for the group. When another user chooses to join the group, the security setting will kick in and either not let them in (private), create a workflow (semi-private), create a notification (semi-public) or allow them to join (public).
By having multiple owners of a group, it makes the workflow process painless and users don't have to wait long to get into the group. It really works well.
But, we went one step farther, an Admin can set those security levels on users attempting to leave the group as well. Why would you want to do that? Consider the security group for users on HR probation. It is probably a group that nobody wants to opt into but most on it will want to opt out. Especially if you are using that group to lock down downloading privileges to keep soon to be fired employees from stealing data. If you set it up right, it's like the roach motel, they can check in but cannot check out.
In our recent survey on AD group management, we found that 60% of organizations are leaving group management up to manual processes. While we agree that managing AD groups isn't always the most strategic use of your valuable IT time, if you abandon the manual and choose to automate and delegate, you can solve a lot of security and productivity issues with these Active Directory groups.
One of the things that jumped out at me in our recent survey seemed to be confirmed by visiting with a number of folks who stopped by our booth at TechEd. People are using Active Directory to secure SharePoint groups!
Our survey showed that nearly 50% of organizations are, and based on the conversations we had with folks in the trenches, that number might even be a little low!
And no wonder, by using Active Directory groups to secure many of your SharePoint groups you get some great benefits.
- It can scale better. Incremental crawls go faster with AD groups.
- AD groups look like a single "user" to SharePoint. No hassles overpopulating security principals.
- Existing AD groups often map well to your current organization. No need to re-invent the wheel!
Since you are using AD groups, make them dynamic wherever possible. By doing so, you only have to look at the groups once, when you create them. After that your SharePoint site group gets updated whenever one of the members falls in or out of the bounds of your query or hierarchy.
By using dynamic AD groups SharePoint site administrators won't face the bottleneck of an overworked AD guy, and they won't have to learn (or be given rights to) Active Directory. Most importantly, the users automatically get properly provisioned into the right groups for their current role.
Dynamic groups have the added benefit of improving your security. When a user changes roles or locations their site permissions change with them automatically. It's the same when a user leaves the organization. As soon as their AD account is disabled, so is their site access.
Everybody wins!
I attended a great webinar by Logic Trends today. In it they discussed their methodology to cleaning up and ensuring the long term health of Active Directory. The first step, as always, is to identify the problem. They have a methodology that begins with AD reporting, in fact, their own AD reporting tool covers some pretty great stuff like what resources AD groups have access to.
This is near and dear to my heart because GroupID is the logical next step...making sure that the correct people are in those groups, in other words, that you have accurate group membership.
Imanami also provides a free Active Directory reporting tool to help ensure that AD is as accurate as it can be. GroupID Reports can give you reports on your users, computers and groups in an easy to digest and very useful format. You can email the reports, schedule them, and generally use them to monitor the health of Active Directory.
The first and quickest hits are going to be:
- Groups with no owner
- Groups with no members
- Computers that haven't logged in in "x" days
- Users and the groups they are members of
With these quick reports you can start determining if you have group proliferation, dangers of token bloat, and excess computer objects. As you go deeper, you can start to track users that don't have department or other important identity information. And, of course, you'll want to use GroupID to solve all of these problems. But first you have to identify those problems. Download the free Active Directory reporting tool, GroupID Reports, and start identifying.
At TechEd every year we try to have a fun cartoon or image to get people's attention as they stroll by our booth. Last year we did the Automated Provisioning Machine. This year, we introduced Active Directory Man.
Active Directory Man is espousing the benefits of Active Directory group lifecycle, the idea that you can expire and renew groups without the destructive process of deleting them. Think about it...if over 90% of organizations use AD groups to manage access to resources, yet about 60% of them manage these AD groups manually, how many of these groups are no longer being managed but are still granting access to users.
Active Directory Man doesn't think that's a good idea. Take a look at GroupID's full AD group lifecycle solution, from beginning to end make sure that only the groups you need are still in Active Directory.
There are two common use cases for kiosk access to Active Directory self service. The first one is very straight forward, allow end users the ability to log in and update their Active Directory profile or search a corporate phone book. We have had the second one less often but often enough that we have taken notice: allow anonymous end users to create an Active Directory account at a kiosk.
The use case for the end user account creation is for partners, customers, temp workers, contractors, etc to be able to create their own accounts that will then grant them very limited access to resources on the network. Things like SharePoint access, phone books, order corporate schwag. Where we come in is that they can create the account and then update their contact information and find other employees.
There are some technical hurdles to overcome. Most often these kiosk users will be in a different forest so you have to be careful with trust relationships. You need very limited rights for a kiosk account to create accounts and only create accounts. You absolutely need workflow on that user creation. And you need a way to force them to update their information upon account creation (which is tricky given the lag time that can happen waiting for workflow approvals).
All of this is very achievable given a flexible enough web based Active Directory self service tool but to do it right you will need to manage all of the layers of security on it very closely. We recently built a pretty nice prototype, let us know if you want to see a demonstration of it in action.
We recently commissioned a study with Osterman Research to find out what organizations use Active Directory groups for. Part of it is selfish, we make Active Directory group management solutions, and it would be nice to know that the market is big enough. But the other, more important, factor is to make sure that we are evolving and innovating in the right direction.
So, to put it simply, AD groups are used for security. Surprisingly, much more than for email. Securing resources accounted for the top two spots by a big margin. And security groups, rather than distribution lists, accounted for 4 of the top 5 spots. Take a look at this, according to the survey, the five most common uses for AD groups are:
- Grant access to files and folders (93 percent)
- Grant permission to systems (78 percent)
- Applying Group Policy Objects at the group level (73 percent)
- Sending email to distribution groups (66 percent)
- Send email to mail-enabled security groups (43 percent)
Didn't you expect to see email at the top somewhere near 100%? Keep in mind that the respondents are all AD & Exchange users admins, they would know this stuff.
For Imanami, this is important news, many competitors are moving into the group management space in fits and starts but everyone seems to focus on distribution lists not security groups. We are ahead of the pack and will continue to be.
Check out more results from the study on user and group management. And let us know if you'd like to see a demo of how we can help manage the accuracy of your Active Directory security groups with GroupID.
I am the kind of person that thinks that a person can never know too much.
Clearly I am not the person who should be in charge of securing the enterprise!
I was reminded of this in a great slideshow which says 87% of organizations think that their employees have too much access to information not related to their job.
So much of an IT professional's job these days involves making sure that their users have access to the information and systems that they need to do their jobs, but restricting them from accessing information and systems that they are not authorized to use or see.
And it isn't like this is a stationary target. Users come and go. They change jobs and locations and all of that changes what they should have access and visibility to.
So what does a busy IT professional do? Skip another lunch? 52% say that they already can't keep up with access-change requests.
I say automate!
North of 90% of IT professionals are using Active Directory to control access to files and folders. Almost 80% use AD to grant permission to systems, and more than half are using it to control access to SharePoint. That means that you are likely using security groups to secure and grant access to those resources. Why not create those security groups up as dynamic "Smart Groups" with dynamic membership?
Now, when Jane end user gets transferred to Topeka, all her AD groups (security and distribution lists) get updated. When Joe gets hired into the engineering organization in Buffalo most of his groups are automatically provisioned based upon LDAP queries and workflow you defined.
Your end users don't have to call for a support ticket, and your IT team doesn't have to make important business and security updates manually.
You can use your extra time learning new things on Wikipedia!
I recently watched a demonstration of Forefront Identity Manager's implementation of dynamic security groups, a feature that GroupID Automate has had since its inception. The FIM query designer appeared to do a pretty good job and I was beginning to see where it would fit into the marketplace when at the 45 minute mark, the speaker dropped the bombshell.
The speaker says, "this group is something that is defined within Forefront Identity Manager; it is not an Active Directory group but of course we can use the connector for Active Directory." Going through the rest of the presentation, they show a flowchart of FIM that makes it appear that FIM creates the group in an object store that has to be synchronized with the metadirectory which is then synchronized with Active Directory.
In my experience in IT and life in general, moving parts are bad. The fewer moving parts the less that can break. That's why I titled this post, "Dynamic security groups in Active Directory." Because that's the key part, put the darned group where you want it to be in the first place.
I have done a chalktalk on creating a dynamic security group in Active Directory using GroupID and it couldn't be simpler. And the group is created directly into AD, exactly where you want your AD groups.
Years ago, I heard a stat that the average user gets provisioned into 16 directories when hired and deprovisioned from only 10 directories when leaving. For the math challenged, that leaves the ex-user active in 6 directories. Which is, of course, a problem.
Today's IT infrastructures are big and complex and there are lots of nooks and crannies for users' identity data to hide in. IT might not even realize how some of it got to where it was. This makes deprovisioning a user even more important.
The obvious route to take is to have a directory synchronization tool that can delete user objects out of each and every directory or database (or set them to inactive, or change the password, or logically delete them, or disable them or expire them). But this is assuming you know all of these databases and directories.
At Imanami, we advocate this approach with one extra safety valve. Security groups, get these users out of each and every security group that they were in. By doing this, you add an additional barrier. If the user somehow can get into the network, they won't have access to anything. This is an additional case for having a strong group management solution: if you are granting access to resources and systems with security groups, then taking a user (or ex-user) out of those security groups now denies them access.
You can read more about how Imanami manages dynamic Active Directory security groups, take a look at our chalk-talk, or contact us for a demo. If you want to deprovision your AD users completely, get them out of the groups.