Did you explicitly add the AD group  to the corresponding SharePoint Group?
This is required for the users  defined in the AD group to actually have
permissions. You should also know that there are sometimes issues with
SharePoint being able to read membership from nested groups  so its best to
stick with one AD group containing users added  directly to a SharePoint
group. This is what it means to manage  security using AD alone.

Yes. Each SharePoint group  has one AD group associated with it. The
groups are not nested in AD. We are running this in a clean VM using
only the new groups  we've created each populated with a single  test
user representing each access  level. When we do this, specifically
approvers don't get the approve/reject buttons. However, explicitly
listing a user  in the SP group works  immediately.

Are these nested group  issues documented anywhere? Our AD structure
relies heavily on nested security  groups, and we don't really want to
have to maintain security in two places. Do you happen to know if
there's a fix in the works?

I haven't seen the problem  documented anywhere other than in emails that
I have exchanged with other consultants. But I have talked to several
other people who have seen the issues firsthand. It is an intermittent
problem that can't always be replicated. I haven't even seen any blog
postings about this one and I don't know of any fix in the works  either
other than avoiding nested groups. A lot of people may not see it
simply because you can't nest global groups  unless you are running your
Active Directory in Server 2003 native mode.

Could you elaborate on the issues with nested AD groups  so that
I can pass the info on to our admins? I did a quick search of the
list and web and didn't find anything obvious.

In a Server 2003 native AD you can have Global groups  that are members
of other global groups. Several other Mindsharp instructors and I have
noticed that sharepoint  seems to have a problem  pulling the membership
of the AD group  nested in another AD group when it is added  as a member
of a SharePoint group. In other words, users  in the nested AD group
don't get rights in SharePoint like they should. This is only when
nesting Global groups and that can only be done once your AD has been
promoted to Server 2003 native mode. I haven't seen it documented
anywhere else either.

I've been using nested AD Global groups  exclusively and have not set  up
any SharePoint groups. I've assigned permissions only to AD global
groups (and a few AD users) in SharePoint. I have not seen the behaviour
you describe at all.

I noticed that you said that this behaviour occurs intermittently when
you add an AD group  as a member of a SharePoint group. Does this mean
that the behaviour does not occur unless SharePoint groups are used?

I believe all reported occurrences have been when using SharePoint
Groups.

How about if you don't add them to sharepoint  groups - what if you apply the
permissions directly to the ad group  ?

The only time I have had this a full profile import sorted it but that was in
2003 and I couldn't say why it fixed it on that occassion other than that it did

Might be worth a try.

Can you help me to understand how you'd do this? How would you apply
SP permissions directly to an AD group?

Add the group  as a user  (I know - it's counter-intuitive).

I just tried adding  the AD group  as a user  in SP and gave it the
approve role. Then changed the approval workflow for pages to ONLY
contain this AD role. I created a page and logged in as a user within
the AD group and was not able to approve. When I look at the workflow
itself it is assigned to correct user (ie. the AD group).

Any thoughts? Is something hosed up? This should work right?

I'm not well versed with workflow, but it seems to me that your
configuration should work. I can only think of one explanation:

- Did you make any changes in Active Directory for this test? If so and
if you have multiple domain controllers in your domain, did you allow
time for Active Directory to replicate to all of the DCs?

If not, then I don't see how your test could have failed. Have you
tested the approve role/permission level?

There is an issue that creeps up occasionally like this:

You add a user  to a SharePoint group  with some privilege, let's say
contributor. You then assign an AD Group containing that user, with
lesser permissions like Read, directly to a permission level. What we
are seeing (haven't nailed this down as to when/why) is that the AD
Group will override the user permissions, and they end up with Read, in
this example.


Now that I read this thread, it is possible that it depends HOW the
permissions to the user/group are applied. i.e. AD Group into SharePoint
Group vs. AD Group to Permission Level vs. User to Permission Level vs.
Users to SharePoint Group.


I don't have the answer, but I wanted to let you guys know there are
some issues as above. Todd Bleeker found this originally, but I don't
know if he has the exact circumstance documented that makes this happen.
I will try and track this down this week.

Any idea on how to resolve this issue? I went into our SP site and removed
all the user  created groups. Then created a user in SP from the AD group
with approve. This didn't solve the issue so I deleted the new user. Then
created a SP group  with Approve access. When explicitly added  to the group,
my user can approve. However, users  in the AD group can't approve once
added to new SP group.

I understand this SHOULD work and I'm pretty sure it did at one point for
us. In fact, I think we have screenshots from when it did. Any idea on
what I could do to fix the issue?

could please clarify? It sounds like you have TWO scenarios that
do not work:

1) AD User -> AD Global Security group  -> SP User

2) AD User -> SP Group

3) AD User -> AD Global security  Group -> SP Group

From what I've read so far, I would expect #1 and #2 to succeed and #3
to fail, but it sounds like you have #1 AND #3 failing, is that correct?

You might want to check your AD group and make sure that it's a global
security group and not some other type (i.e. distribution group, local
group...)

You are correct. #1 and #3 are failing. I'll have to check the AD groups
and how they were setup. I'm pretty sure they were setup  (and working)
recently. At some point we deleted and recreated site collections and reset
security in the site collections. No changes have been made to the AD
groups since they were working.

the issue he had was due to site corruption and should not
happen with a healthy MOSS/WSS install.

I would open a call with Microsoft PSS and let us know how you fix it
. I have no idea what's up with that.

Interestingly enough, over the weekend we did have a power outage and the
box running the server went down. Very well might explain how corruption
might have happened. Although a different box also went down and that one
seems fine. Go figure. I'm sure Microsoft PSS will have this issue
resolved much quicker than me rebuilding my test site.

That being the case, you should be able to create a new sites collection
and try the same thing in there - if it works  you have a corrupt site

I've created a new site definition and the same behavior is being seen. A
user explicitly added  to a SP group  can approve. A user  or group granted
approve access  through an AD group cannot approve.

Can someone verify that they are actively managing user access in a
Sharepoint 2007 site collection through AD groups? It would help my sanity.

UPDATE: I tried the exact scenario I've been trying to get working in the
Virtual PC image that was provided in the developer summit training course I
took back in January. I'm getting the same results on this image as I have
on two separate MOSS installations here.

I spoke with a consultant about this today. They told us that the
problem stems from users  having permissions on items through multiple
group memberships. The recommended not using nested groups  from
SharePoint.

The inference is that SharePoint does not use the age-old 'additive'
permissions rule. NTFS, which all of our AD infrastructures are
(basically) built to support, resolves multiple permissions through
multiple group  memberships on a folder by adding  grant permissions (most
permissive on grant) and by adding deny permissions (least permissive on
deny). SharePoint, it seems, does not use these two rules.

Two typos and an omission - I meant to say, "They recommend not using
nested AD groups  for SharePoint."

In our case there are no nested AD groups. I used a Virtual PC image that I
got from Mindsharp when I took their training. Created a new AD Group, and
a new AD user  that I added  to the new group. Then created a new Publishing
Portal site collection. These are the steps I'm going through in SP:
Create a new user w/ approve role using the AD security  Group.
Customize the default workflow for Pages and set  the new user specified in
the previous step as the approver. Remove the default Approver group  as an
approver.
Create a new page and submit for approval.
Login as test user that's in AD Security Group specified as an Approver.
No Approve/Reject buttons are shown.

I've verified the workflow task, and it is assigned to the correct group.
As I said, I've tried this on 3 different severs -- none of them have
complex ADs. I'd love for someone to prove me wrong - what could I possibly
have done to cause SP to not read users  in AD Security groups  (yes, they are
set as Global)????

Is the ad group  mail enabled ?

Personally I'm thinking this is more an "AD group with workflow" problem
than an "AD group with MOSS" if you see what I mean

Here's a new wrinkle. Users with Approve access  given through AD Groups CAN
approve by going through the workflow button and directly approving the
task. So now it seems, the real problem  is the Approve/Reject Buttons
aren't showing.

Looks like we posted the same question simultaneously!

That's interesting about the full profile import fixing it. Perhaps MOSS
is storing group  membership information with the profiles? That would be
bad....

I'm thinking it was more likely an ad syncing issue that sorted itself in the
time it took me to import !

I difnt know if it was caching group  memberships tho hence me thinking that the
import might have sorted that (but then a reboot would too)