Ludo's LRT blog

Here in the LRT team at MMU we would love to use AD (global security) groups to target SharePoint web parts.  We are using MOSS 2007.

Unfortunately, it doesn’t quite work, although it used to some time ago.

Here’s a pictorial guide to what happens when we try to create a new AD group and use it in SharePoint:

1. Create a new global security group in AD.mmu.ac.uk.  Incidentally, inside our own LRT container. 
2. Populate the group with a number of users who already have access to our test SharePoint web portal.
3. Pick a shared web part, edit its properties, go to Advanced.
4. Under Target Audiences, try typing in the name of the new group and clicking the ‘tick’ icon to have it recognised.  It isn’t recognised, so SP underlines it in crinkly red and italicises it.
5. That can’t be right!  The group is right there in the AD!  Just to check, let’s delete the group name, then click on the ‘book’ icon next to the text box and look in there.
6. The ‘find audiences and groups’ dialogue box opens.  Select ‘Distribution / Security Groups’.  Try typing part of the name of your group and click on the magnifying glass.  The group is not found.
7. OK, let’s try all the above again from step 3 onwards, but first we’ll go to the SSP and do a full profile import.
8. Nope, still doesn’t work.

However, some groups that we have created do eventually appear in SharePoint, only with not as many members as they should have.  For instance, the group ‘hlss-election’ wasn’t appearing before.  Now it appears, with only one member.  It isn’t recognised in the ‘Target Audiences’ box if I type it in and click ‘Check Names’, but it is available using the ‘Browse’ feature (book icon).

If we ‘Browse’ the book, we can see that hlss-election has one member.  However, in AD it has three members.

One thing that might be of note is that I had added some text to the group’s Description field in AD Users & Computers before the last import.  This was suggested as being important in a blog post we found on the subject (look for Jason in the comments).

–Ends–

Well, here’s a weird SharePoint (MOSS 2007) error. While testing the correct way to set up folders with different permissions in the same Shared Documents Library, I was very surprised to see the following error.

I have set up a subsite on our test farm that does not inherit permissions from the main site collection above. My ID is the only one in the Site Owners group. I have created two subfolders in the Shared Documents library but not yet altered their permissions.

I am a site owner. However, when I try to Edit Properties on either of these subfolders, I get “Error: Access Denied” and am asked either to sign in as a different user or request access.

I tried logging in both with my own ID and as the site collection administrator to no avail.

I have even tried requesting access from myself, have received the email, clicked on the link, verified visually that I am indeed in the owners group, and then tried to edit the subfolder properties again, but without success.