Tag Archives: Active Directory

All People in SharePoint 2010

Another post available on sp365 about getting a list of All People in SharePoint 2010. This list was available in 2007, but was removed in 2010. See how to get it back! http://sp365.co.uk/2012/04/all-people-in-sharepoint-2010/

Advertisements

Simplifying SharePoint User Management

One of the biggest headaches I’ve heard from SharePoint users and administrators is the ability to manage users, or rather the lack thereof. It is a large task to fully understand it all, and I hope to clarify some of it now.

Quality user management is by far the most lacking area within SharePoint. There are 3rd party add-ons available which help ease the task, but now you’re looking at spending more on top of your existing investment in SharePoint. I think it’s ridiculous that I can’t click on a user in SharePoint and see all groups that person is a member of… Seriously! Can’t do that, you can in AD, but you can’t in SharePoint. I think the SharePoint guys could learn something from the AD guys…

So I take a few moments to cover some of the heads ups, gotchas, and oopsies with managing users and permissions within SharePoint.

A quick primer

Permissions in SharePoint can be very intricate and act a lot like Active Directory on how you may protect a folder or file on a network drive. You can pull in a group (AD or SharePoint group) of users and specify that this group of users should have write access to this list, and others should have only read access. You can even bring it in tighter and say that one or two users have write access to a single item within a list, and hide it from view for all others.

Adding users and groups is a simple task and can be found almost anywhere on the internet, so I won’t walk through that here. Also, check out this blog Five Key Steps to Managing SharePoint Users for some great pointers on governance and management. We will be taking a different direction in an effort to help clarify using permissions and user management in SharePoint.

Using groups of users to simplify

There are two major methods which can be utilized to manage users. The first and the more popular method, usually seen in larger deployments, is to use Active Directory groups. This allows your IT department to manage their AD groups as usual, and when users are added to their AD groups, they’re in SharePoint automatically. The other method, usually smaller deployments, is to add users directly into SharePoint as individual user accounts.

Use groups whenever possible, it should be an extremely rare case when you need to specify an individual user anywhere within SharePoint permissions (not to be mistaken for the Assigned To field ;). Site collection administrators have to be individual users, otherwise everywhere else use groups, you’ll be glad you did. A group can be an Active Directory group or a SharePoint group.

  • If you’re using Active Directory groups, still throw that group into a SharePoint group. Using SharePoint groups will give you more flexibility in the future. Consider this example, if you add your HR AD group to SharePoint and give them specific access to their sub site, and in a year your executives want access into that site, you can
    • Add the executives to your AD group HR (which wouldn’t be right since they’re technically not HR users)
    • Add the Executive AD group into SharePoint and try to replicate all of the permissions the HR group has
    • Add the Executive AD group into the SharePoint group the HR AD group is in.
    • Which sounds easier? Apparently the last one would be easiest, if this is how you configured it initially.
  • If you’re not using AD groups, start! But if you can’t for whatever reason, and you’re only pulling in individual users, then make sure they’re in SharePoint groups. This will make managing permissions the easiest throughout SharePoint.
    • One pain point is that you cannot put a SharePoint group inside of another SharePoint group. So using the example in the previous bullet, we cannot add the Executive SharePoint group into the HR SharePoint group, instead we’ll need to try to replicate their permissions as much as possible.
I recommend using Active Directory groups whenever possible. Your users are already in AD groups, somewhere in your organization, and in most cases these groups reflect the governance within SharePoint, therefore your groups would make most sense to manage your users.

Know where you are!

It’s vital to know where you are when you’re managing permissions. It’s very easy to get spun around and start changing permissions on something you didn’t mean to. The best way to know where you are is to look at the URL and the page title. The combination of the two should tell you where you are and what you’re managing.


Document Library Permissions


Site Permissions


Sub Site Permissions

Who has access to what?

Yup, the best question and the hardest to answer. Again, there are 3rd party add-ons which can answer this quickly, and if this is a reoccurring question I suggest checking them out. However, if you can’t swing the cost of another application, here’s how I do it.

First, go to what you have the question about. For example, if you want to know about a list, go to List Settings. If you want to know about a site, go to Site Settings.

Second, click Permissions (Permissions for this list/library or Site Permissions for Site Settings). This will list all groups which currently have access to this list or site. Simple enough right? Welp, I’d bet you want to know who is in each group next right? From here, make note of the groups names. No, you can’t just click on them, that manages their permissions on the list/site.

Third, go to Site Actions > Site Settings > People and Groups. Now you can click on each group and determine who’s in what group, and who has access to what. Unfortunately this can be a painful exercise. If you’re using AD groups, you might be off the hook, simply pass the ball to your IT dept and ask them to give you a list of users per group. If you are the IT dept, sorry…

All People is for the entire site, NOT your current site!

This applies to SharePoint 2007, Microsoft removed this from 2010 (one improvement). You probably have seen the link in the quick launch while managing users (Site Settings > Site Actions > People and Groups) which says All People. You may click this link and see everyone. This is great, a simple list of everyone in SharePoint. Now go to one of your secure sub sites and do the same, and you’ll still see everyone. Annoying right? This list shows all users in SharePoint (in your site collection, not the current site). When you’re in your secure sub site, you may want to remove people from All People since they’re not supposed to have access to this site, unfortunately if you remove a user or group from this list you’ll remove them from SharePoint completely (unless they’re member of an AD group which has permission).

All People of the site, not the sub sites. But is it all of them?

One other weird thing that happens with this list: this list is showing you everyone who has a login account into SharePoint and has already logged in or has been added directly. If you’re not using AD groups, then you’ll see everyone who has been added to SharePoint. If you’re using AD groups, you’ll only see the users who have actually logged into SharePoint at least once. If an AD group has 200 users, and only 100 have logged into SharePoint, you’ll only see those 100 users here, the other 100 have permission to login, but until they do they won’t show in this list.

#$&%! Limited Access

“How do I use Limited Access? I don’t see it as an option.” “What does the user have limited access to?” are my two favorite questions. If you see Limited Access, curl up under your desk and cry. While you’re under there take a quick nap and then collect yourself and come back up because you have a lot of work to do. Limited Access means that user or group has some sort of unique permissions to something in your site. If you grant a user permission to a single item or list, you will see this same user under Site Permissions as Limited Access. There is no easy method to determine what and where the user has this limited access. You will also see this user as Limited Access throughout SharePoint for any list or sub site that inherits from the site.

Let me explain a different way. John Smith is a member of the Members group and the SharePoint administrator determines that he needs unique permissions to the Shared Documents library as a designer so he can approve documents. Instead of creating a new group (groups are best) and manage the group, the admin adds John Smith directly to the list. Instantly, the site permissions will list him as Limited Access, and each list, library and site which inherits the permissions also shows the same. A month later that admin looks at site permissions and sees John Smith listed as Limited Access and asks how did that happen? How do I find out what he has access to?

There are a few methods I’ve found in correcting this issue.

  1. SharePoint 2007 – Navigate and look at the permissions on every list in SharePoint. This way you’ll find which list has unique permissions. However, if unique permissions were setup on the list item, say one document in a library, then you’ll need to check permissions on every single item within SharePoint. This could be hundreds to thousands of items. It’s okay to cry.
  2. SharePoint 2010 – One improvement that makes this a little easier. Instead of having to navigate throughout the entire site to find what is unique, SharePoint 2010 now has a basic reporting tool which will provide this to you. When looking at Site Permissions, you may see a little bar above the list which states there is uniquely secured content. Click the link and it’ll show you the few lists which are unique, and which items within a list if applicable. This will make reviewing your lists a little easier.
  3. The second method is easier and a little more effective. Go to Site Permissions (Site Actions > Site Settings > Site Permissions) and remove the user. Don’t worry, this will only remove the specific permissions for the user. The user’s existing permissions through other groups will remain.
    1. This method will remove the user’s permissions, but not reset the list/library/item’s permissions to inherit again. That you’ll still need to find and fix.
Is that it?
Probably not, but outside of the normal tasks (adding users to groups, creating new groups, specifying permissions for groups), I think this covers some of the big headaches with permissions management in SharePoint. If I missed something, let me know!

SharePoint 2010: Forms Based Authentication using Active Directory

This post is a close mirror to my other post SharePoint 2010: Claims Based Authentication using .Net SQL Membership Provider, just tweaked to use AD instead of SQL. In this post I want to use Active Directory instead of SQL, and allow users to login using a friendly form instead of the ugly Windows grey authentication window.

SharePoint 2010 has a great feature called Claims Based Authentication. You specify this when you create your web application. If you created a web application as Classic Mode Authentication, you can change it to Claims Based Authentication, see this blog post http://weblogs.asp.net/sreejukg/archive/2011/03/25/change-sharepoint-authentication-from-classic-mode-to-claims-based.aspx on how to change it.

Our plan of attack is

  • Modify your web application, central admin and the web services’ web.config files.
  • Update web application to use forms.
  • Install free feature to add user management to SharePoint.

Modify your web application, central admin and the web services’ web.config files. This part can be a little tricky. We need to modify the web.config file for your

  • Web Application so your web app can authenticate users
  • Central Administration so users are recognized
  • Web Services so users can log in.

Update the web application’s web.config file.
IMPORTANT: These steps will have to be completed on every web front end in your farm.

  • Go to C:\inetpub\wwwroot\wss\virtualdirectories\appname.
  • Copy the web.config to web.config_preCBA as a backup.
  • Open the web.config file.
  • Find <roleManager add the following provider highlighted below. Change the items in green to match your domain.
<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false"> 
<providers> 
<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, 
Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> 
<add name="CONTOSOROLE" type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, 
Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="contoso.com" port="389" 
useSSL="false" groupContainer="DC=contoso,DC=com" groupNameAttribute="cn" groupMemberAttribute="member" 
userNameAttribute="sAMAccountName" dnAttribute="distinguishedName" groupFilter="(ObjectClass=group)" 
scope="Subtree" /> </providers> 
</roleManager> 
  • Find <membership and add the following provider highlighted
<membership defaultProvider="i"> 
 <providers> 
<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, 
Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> 
<add name="CONTOSO" type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, 
Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="contoso.com" port="389" 
useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" 
userContainer="DC=contoso,DC=com" userObjectClass="person" userFilter="(|(ObjectCategory=group)
(ObjectClass=person))" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" /> 
 </providers> 
</membership> 

Update central admin’s web.config file
IMPORTANT: These steps will have to be performed on all servers hosting central admin.

  • Go to C:\inetpub\wwwroot\wss\virtualdirectories\portnum.
  • Copy the web.config to web.config_preCBA as a backup.
  • Open the web.config file.
  • Perform the same steps above on this web.config file.
    • The roleManager and membership sections may look a little different. You’re only adding the highlighted elements, not modifying it to match.

And that should take care of your Central Admin.

Update web services’ web.config file
IMPORTANT: These steps will have to be completed on every web front end in your farm.

  • Go to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken.
  • Copy the web.config to web.config_preCBA as a backup.
  • Open the web.config file.
  • Find </configuration> (bottom of page) and add the following right above it
<system.web> 
<roleManager enabled="true" cacheRolesInCookie="false" cookieName=".ASPXROLES" cookieTimeout="30" 
cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true" cookieProtection="All" 
createPersistentCookie="false" maxCachedResults="25"> 
<providers> 
<add name="CONTOSOROLE" type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"  server="contoso.com" port="389" useSSL="false" groupContainer="DC=contoso,DC=com" groupNameAttribute="cn" groupMemberAttribute="member" userNameAttribute="sAMAccountName" dnAttribute="distinguishedName" groupFilter="(ObjectClass=group)" scope="Subtree" /> </providers> 
</roleManager> 
<membership userIsOnlineTimeWindow="15" hashAlgorithmType=""> 
<providers> 
<add name="CONTOSO" type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="contoso.com" port="389" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" userContainer="DC=contoso,DC=com" userObjectClass="person" userFilter="(|(ObjectCategory=group) (ObjectClass=person))" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" /> </providers> 
</membership> 
</system.web> 

And now we’re done with the tricky part.

Update web application to use forms. Next we’re going to tell Central Admin about our desires and tell the web application to use our configured authentication.

  1. Go to Central Administration > Manage Web Applications.
  2. Select your web application and click Authentication Providers.
  3. Click the zone marked as Claims Based Authentication
  4. Scroll down to Claims Authentication Type.
  5. Check Enable Forms Based Authentication, and enter SQLMembershipProvider and SQLRoleManager in the two options
  6. Scroll to the bottom and click Save.
  7. Close the Authentication Providers window.

Browse to your site and if you’re lucky, you should see a login prompt, and you should be able to login as the user we created before or a Windows account.

Pretty plain eh? Check out my other blog post on how to customize this page some more.