none
Sharepoint 2007 Active Directory groups can be added but get no rights

    Question

  • When we add AD groups to a SP group on a site, it does not confer any rights to the members of the AD group.  Is this a no-no or is something wrong in our setup?  The AD group can be "Found" and the name check confirms it.
    Wednesday, September 24, 2008 9:54 PM

All replies

  • AD groups can be added to SharePoint groups and they should be allowed the correct access.  Are you seeing any specific errors when a user tries to access the sites?
    Robert Stark MCTS - MOSS 2007 MCTS - WSS 3.0 ---www.thesharepointranch.com --- cas.excell.com
    Wednesday, September 24, 2008 11:36 PM
  • We see no specific error - just no access.  We've checked this with several AD groups that we know are security and not distribution groups. 

    What we are doing is adding an AD group, which is found in the check names, to a site-specific SP group.  For example, we have a site group Site_Members created as a site group in SP using IE7 and SP 7.  We have a domain group DM\Group_Members, which - in the add names or groups - is checked, found, and added.  Users who are members of DM\Group_Members and no other SP group do not get the access that members of Site_Members gets.  No errors, just no access.
    Thursday, September 25, 2008 1:45 PM
  • Hello Tony,

     

    I think you the issue you meet like this:

     

    On MOSS 2007, individual Users of a security group were added on the web application were able to browse the site. When the security group was added to the web application, we got “access denied” error message.

     

    If so, I think the root cause of this issue may be that you created this security group into “Domain Local” scope. As a solution, try to create the group with global scope. Then, test the issue again. Have a nice day! Thanks!

     

    Regards,

    Lionel

    Monday, September 29, 2008 2:56 AM
  • Thanks for the answer, but it appears to not be the cause.  It took a while to get a response from our IT department.

    We've found that the groups are defined as Domain Universal.  At least that is what the IT group is telling us. 

    They - the IT department - have no idea why this would not work.  But it continues to not give rights via an AD group.
    Tuesday, September 30, 2008 9:31 PM
  • Tony,
    Is this happening at a top-level site, or a sub-site?
    Wednesday, October 01, 2008 1:48 PM
  • Two Levels down - sharepoint top.com/level 1/problevel.

    We aren't allowed to work at the top level.  I administer from level 1 down.  Some testing shows the same problem at level 1, but we've not put the same level of work attempting to make this work.

    We are attempting to switch from having to always enter people on the Sharepoint groups as well as having IT enter people in AD groups.  We want to just use the AD groups which are maintained by IT as people are added or removed from work locations.
    Wednesday, October 01, 2008 2:15 PM
  • Have you tried connecting to a document library using 'Start > Run > UNC path'?

    Example: \\sharepoint\site-collection\site\doclib\

    Wednesday, October 01, 2008 3:16 PM
  • I apologize, but don't see the relevance of this post:

    Have you tried connecting to a document library using 'Start > Run > UNC path'?

    Example: \\sharepoint\site-collection\site\doclib\
    We are trying to display various webparts to only select groups.  We only want some lists to appear to specific groups.  We only want some groups to have write access.  Getting to the document library is not the problem.  Assigning rights to who can get there is.


    Wednesday, October 01, 2008 3:47 PM
  • I apologize for misleading you Tony, however you failed to mention any of that in your initial post or throughout this entire discussion.

    The reason for attempting to view a DocLib via the UNC path to isolate the problem and verify that your AD Security Groups are working, while taking IE, and any other customized coding/incorrect configuration your site(s) may have.
    • Edited by DDavis485 Wednesday, October 01, 2008 4:15 PM
    Wednesday, October 01, 2008 4:10 PM
  • This also caused us to try another test and now we have more info.  So thanks!

    We have the following setup:

    Sharepoint 2007 Site at portal.xxxx.com/Top/Level_1 with

    A group SPSiteMembers which contains an AD group ADSiteMembers and an  AD user ADUser.  ADUser is not a member of ADSiteMembers.
    A doc library SiteLibrary only accessible to members of SPSiteMembers
    A Summary Link Web Part WebPart with the Target Audience set to SPSiteMembers

    Both ADUser and members of ADSiteMembers can see the items in the SiteLibrary.

    Only ADUser can see WebPart.  No members of ADSiteMembers can see WebPart.


    Wednesday, October 01, 2008 4:46 PM
  • Personally, I would not recommend creating site-specific groups for any site in SharePoint for the very permission problems you are running across.  Merely creating a group in SharePoint and assigning an AD security group to it does not give permission to the AD security group's members automatically.  You must then permission the SharePoint group to give it access to the site, but I've seen even THAT not work before in MOSS 2007.

    There are built-in SharePoint groups to use for a site collection.  They are <SITE> Owners, <SITE> Members, and <SITE> Owners, where <SITE> is your site collection's name.  These generally are created when the site is created (depending on the template chosen, and depending on vigilence of the administrator/developer creating the site, in the first place, to find out they need to go back and create these groups when they chose a template that does not carry these built-in groups automatically).  You should be assigning AD Security Groups to THESE roles/SP groups.  Then you will have the access to the site that you need.

    If you have deleted these groups, or they were never created, they should NOT be MANUALLY re-created.  There is a feature when you have all site groups listed, on the toolbar, to create those groups - I don't remember what it was called, and this was at my last SP Admin/Dev job 5 months ago - I'm doing straight .NET development now.  But the feature is there and you should title them <SITE> Owners, <SITE> Members, and <SITE> Visitors when prompted to avoid confusion when you are putting AD groups in those SP groups.

    -Tom



    • Proposed as answer by navyjax2 Wednesday, January 07, 2009 5:47 PM
    • Unproposed as answer by Mike Walsh FIN Monday, January 12, 2009 3:42 PM
    Wednesday, January 07, 2009 5:44 PM
  • The groups you mention are there - we just need better functionality.  We do have the Owners, Administrators, and  Members groups.  We need more differentiation.

    We want to have sections of the site only available to select people - but we want to use an AD group for those people because that removes the necessity of having to assign the person to two groups - one AD and one Sharepoint.

    We don't want to make the users click through to another - specific to them - web site which only offers one or two items of the whole set they need to use - Sharepoint is slow enough without having to open an extra extraneous site.

    All the docs say this should work.

    Again, we have the following setup:

    Sharepoint 2007 Site at portal.xxxx.com/Top/Level_1 with

    A group SPSiteMembers which contains an AD group ADSiteMembers and an  AD user ADUser.  ADUser is not a member of ADSiteMembers.
    A doc library SiteLibrary only accessible to members of SPSiteMembers
    A Summary Link Web Part WebPart with the Target Audience set to SPSiteMembers

    New Info

    SPSiteMembers is not the same group as <SITE> Members - it is a subset of that group.

    ADSiteMembers is used to control access to various network shares as well as to allow certain content on the Sharepoint site.

    <SITE> Members can see the basic site, SPSiteMembers can see more components on the site then <SITE> Members

    <SITE> Owners can assign AD groups to become members of SPSiteMembers

    We want to have several levels of access - we will add a SPSIteMembers2 (with ADSiteMembers2) and a SPSiteMembers3 (with ADSIteMembers3)  each with access to a specific doc library and web parts.  Members of <SITE> Members will not see these doc libraries or web parts, and members of other SPSiteMembersX will not be able to see any but there own doc libraries and web parts.

    Current Results

    Both ADUser and members of ADSiteMembers can see the items in the SiteLibrary.

    Only ADUser can see WebPart.  No members of ADSiteMembers can see WebPart.
    Monday, January 12, 2009 3:35 PM