Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

AD to SP Permission Issue

  Asked By: Jessie    Date: Feb 21    Category: Sharepoint    Views: 4761

I have been assigning permissions groups in SharePoint by using previously
existing Active Directory Groups.

For instance:
I have a Group in SharePoint 'Expenses-Contribute'
And the only memeber of it is a A.D. group 'AccountPayable'

I'm having one particular issue with this setup with Workflows.
I've created a simple workflow in SPD, that on creation of an item in a list,
the workflow updates a columns value. The problem is that even if the creating
user of that Item is in the 'AccountsPayable' AD group. The workflow returns a
'Access Denied' error. Although the 'Expenses-Contribute' definitely has
permissions to 'Edit List Items'.

And to prove that (here's why I mentioned the permission setup)
When I specifically Add an A.D. User (that was in the 'AccountPayable' group) to
the S.P. Group 'Expenses-Contribute', when they create a new item the workflow
runs without issue.

Has anyone run into this issue before?

I have noticed some other oddities with setting up permissions this way. Is this
a bad model for SharePoint? To me it's the easiest with
Pre-Existing,well-structured A.D. Groups



8 Answers Found

Answer #1    Answered By: Jaferry Khan     Answered On: Feb 21

This follows along some very recent posts to this group. Check the most recent
posts by Paul Stork to find the answer to this one.

Answer #2    Answered By: Davin Knapp     Answered On: Feb 21

There are several places in SharePoint where the use of nested groups  causes
a problem. This may be one of them. Try adding a user  directly to the
Expenses-Contribute group  and see if you still have the problem. If you do
then we need to keep looking. If not, then it's a case of nested groups
being a problem. In general try to stay away from using nested AD groups
for anything in SharePoint. They usually work in security situations, but
not in things like audiences so its best to avoid them entirely.

Answer #3    Answered By: Deidra Best     Answered On: Feb 21

As I
stated below, the problem  does not occur if I directly add  the user  to the
'Expenses-Contribute' group.

The problem with that though, is.. we have pretty extensive groups  setup in
Active Directory. That would be So much easier to be able to nest/use in
SharePoint. If that's just the way it is. I will learn to deal with it.

But, one last try.. Do you have any suggestions of how to work around this, by
still nesting Active Directory groups in sharepoint  without issue?

Answer #4    Answered By: Rosalinda Merrill     Answered On: Feb 21

Could you not add  the AD group  directly to the permission  structure in
SharePoint instead of housing it in a SharePoint group?

Answer #5    Answered By: Yogendra Zarapkar     Answered On: Feb 21

I do not believe it's an option to assign an AD group  directly to the
permissions structure. You must first create  a SharePoint group, then add  the
Active Directory group to that.

Answer #6    Answered By: Jerad Mercado     Answered On: Feb 21

Well, I haven't had the need to do so here, because I do not have
control of group  creation in AD. However, I do use service accounts
quite often in SPD workflows, and I see AD groups  we I go to add  a user
to the permission  structure of a list...

According to this article:


A full crawl is required after nesting groups, but not if adding an AD
Group directly.

Answer #7    Answered By: Riley Scott     Answered On: Feb 21

Let me see if I can clarify a couple things here.

1. You can NOT assign permissions  directly to an AD group  in
SharePoint. You can add  an AD group as a SharePoint user  just like you can
add an AD user as a SharePoint user. Both create  an object in the
SharePoint database that records the Security Identifier associated with the
group or user in AD. No change is made in AD and neither really references
AD directly after that. Adding an AD group as a user simply means that you
can't add additional AD users or groups  to it like you can to a SharePoint
group. The original issue  dealt with nesting AD global groups inside other
AD global groups. Whether you add the nested AD groups as SharePoint groups
or users doesn't matter. SharePoint has issues with nested AD groups.
Nested groups are only available if you have promoted your AD to run  in
Native mode.

2. The full crawl referred to in the article is not required for
security to work after groups are added. It is required for the Search and
Indexing system to properly pick up the security identifiers that are used
to security trim search results. This article has nothing to do with the
ability to be authenticated to SharePoint through group membership.

3. The only real solution available for the original problem  would be
to use the Accounts payable AD group (the inner nested one) in SharePoint
instead of the Expenses-Contribute group (the outer AD group). The easiest
way to do that would be to create a group in SharePoint (I would call it
something like SpExpenses-Contribute) and add the inner AD groups to that
SharePoint group.

Answer #8    Answered By: Adya Khavatekar     Answered On: Feb 21

Hmm, and this guy seems to have a workaround for the issue  you describe
using code:


Didn't find what you were looking for? Find more on AD to SP Permission Issue Or get search suggestion and latest updates.