AD Group membership not updating in Sharepoint Foundation when adding Active Directory group to Sharepoint group
martedì 19 aprile 2011 14:48
I have Sharepoint Foundation installed with the latest CU updates. It is running on a VMware box (Windows Server 2008 R2 Standard) with its backend on a SQL Server 2008 R2 vmware box. The farm account is a domain user and has been given all appropriate replication rights, etc to active directory.
Everything seems to be working fine except for security integrated with AD groups. When I go to edit permissions I can add individual AD users just fine and remove them just fine and their access is taken away right away or given to them right away. I can also find AD groups in the people picker and add them to the site. When I add new groups to AD, they are found immediately within Sharepoint, and when I delete groups from AD, they are taken out of the people picker right away. Now comes the weird part. When I add an AD group to the site, all users currently within that AD group are given access to the Sharepoint Site. This works for the first time only. Now when I add or remove users from the AD groups, it does not update in SharePoint. For example, I have an AD testuser1 in the AD Group "All Users". testuser1 does not have access to SharePoint. So I add the AD group to the Sharepoint group "Visitors". testuser1 now has read access to the sharepoint site. Now, I remove testuser1 from the AD group, but testuser 1 still has access to the site even though he is not part of the AD group, nor does he have any individual permissions to the site. Now, I add testuser2 to the ad group. testuser2 does not have access to the site, even though he is part of the ad group.
It seems that the only time AD group security is working for me is when I first initially add the AD group to the site. From then on, it's like sharepoint is caching the members of the group and not updating any new adds or deletes from the groups. Any ideas? I am lost on where to go from here as I have tried everything from clearing cache files, rebooting servers, iisresets....
Tutte le risposte
mercoledì 20 aprile 2011 01:17Any suggestions? This is a definite need for our SharePoint solution.
venerdì 22 aprile 2011 17:12106 views and no comments? Any help would be appreciated. I have now brought in AD groups through the sync to see how the audience manager is able to see them. When I add a "Member of" rule for my AD group, it shows that the AD group has 0 members. To me this seems like a communication issue between server and AD.....any help?
venerdì 22 aprile 2011 23:08
Hi, I could not reproduce this as it works as expected for me. Could you please confirm the Authentication type? is it claims?
domenica 24 aprile 2011 16:47Thank you for the response! I am still stuck trying to find a solution. The authentication type is NTLM, not claims, or kerberos. Also, I have my farm administrator account is what is currently running the web application pool of the site. This farm account also has all the appropriate permissions needed in AD (replicating permissions, etc). Still, as users are added to the AD group and removed, Sharepoint does not reflect the security changes....
domenica 24 aprile 2011 16:54This is not the behavior I see with my SPF site. I use SPF to run the COSPUG site (www.cospug.com), and I heavily leverage AD groups for community contributors and the Job Board. I have a Job Board AD group that I put all new companies in so that they can only use the Job Board. I create the new account in AD, then add it to the Job Board AD group. Instantly, I am then able to log in with that new account on the site and create jobs on the Job Board. Before adding to the group, the account has no permissions. The behavior I see is normal and expected as far as my experience goes.
SharePoint Architect || Microsoft MVP || My Blog
Planet Technologies || SharePoint Task Force
domenica 24 aprile 2011 18:23
Hi Clayton, thanks for the response as well! That's how I know it is supposed to work, but for some reason, when I initially add the AD group, it respects the permissions for each member of the AD group. However when I add a new user to the group or remove them from the group, SharePoint no longer syncs with the AD group. It keeps the original permissions given to the users when the AD group was first added. I've waited 24 hours, reset IIS, recycled web apps, but nothing seems to work.
I have, however, renamed my sharepoint web server (the netbios name) from *****web to *****web2. Restarted the server, so now that FQDN is *****web2.***.com. When I access the site now, it brings in the new users that were added to the AD group, but after the initial access of the site, it will no longer accept new users in or out of the AD group. I renamed the netbios back to *****web and restarted. I accessed it from ****web.***.com and it brought in the new users, but again, after the first initial access, it no longer recognizes users added or removed from the AD group. Any idea of why this may be?
Is there any possibility that the sharepoint web server that sits on a Windows Server 2008 virtual machine may be caching the membership of AD groups?
Some things that may help me troubleshoot this issue a little more are:
1) How does sharepoint authenticate against AD? Does it use tokens that may be cached?
2) What account does Sharepoint connect to AD with? The farm account? Does this account need special permissions other than replication in AD?
domenica 24 aprile 2011 18:50
Also if it helps any, my environment is as follows:
Sharepoint App Server - (VMWare, Windows Server 2008 r2) - Hosts Central Admin/ All Services
Sharepoint Web Server - (VMWare, Windows Server 2008 r2) - Hosts Web Applications
Sharepoint SQL Server - (VMWare, Windows Server 2008 r2/SQL Server 2008 R2) - Hosts Sharepoint Databases
Active Directory Server - (Windows 2008 Standard Server SP1) - Hosts Domain Functional: Windows 2003 Active Directory
Also, we have two AD forests. One is AB.Corp, the other is YZ.AB.Corp. All our computers/users/groups sit on the YZ.AB.Corp domain forest.
Let me know if you need any other info. Thanks!
giovedì 28 aprile 2011 16:24Are you adding the AD Group into a SharePoint group or assigning direct permissions? In either case the situation you are explaining is not the expected behaviour. Also what does the "Check Permission" option show. Please try running the this for the users who should no longer have access to the site (Users removed from the AD Group). Also as you explained ur environment, could you confirm if the SharePoint servers are in AB.Corp or XY.AB.corp?
giovedì 28 aprile 2011 16:37
I am not giving the AD group access directly. It is within a SharePoint Group called "SP Visitors". I have tried giving the AD group access directly, but it acts the exact same way.
When I do a check permission for users not in the AD group, it still says that the user has read permission through the "SP Visitors" Group.
I have been trying to track this issue down. What I have found is that when I remove my "User Profile Service Application" from central admin and let the wizard create the user profile service, everything works exactly the way it should with AD. However, we have 15 BCS (BDC) connections in the User Profile Service that the User Profile Sync uses to bring in data from our external sources. When I add all 15 connections back, the AD groups revert to the issues mentioned previously in this post. The User profile sync works perfectly though and brings in all the data correctly. I am wondering if this has to do with BDC connections or secure store connections that are causing the AD groups to error out.
Any idea as to what could cause this?
giovedì 28 aprile 2011 16:41Yes, that could be the issue, would suggest opening a support case to find out what exactly is causing the issue as we have multiple components involved here.
mercoledì 11 maggio 2011 19:46I was curious if the original poster has made any progress with this as I have the same exact issue. Our environments are similar, we have a 3-Tier SharePoint (all 2008 R2, SQL 2008 R2), we only have 1 forest and no BDC connections within the User Profile Service. We have noticied that performing an IISRESET /NOFORCE on both the WFE and APP server, after adding a new user to an existing AD group, solves the problem about 75% of the time, however this is not a solution to the problem.
mercoledì 11 maggio 2011 20:06
I think I have at least cornered the problem, but am not 100% sure yet that it is the correct answer. I think it could be 1 of the following 2 scenarios.
Scenario 1: We have 3 web applications setup on our web server ports 80 - Our sharepoint Web app, 2020 - Our My Site Web App, 2040 - Our Search Web app. We are using host headers (http://sharepoint.***.com) instead of a server name. So we setup our access mappings (Central Admin -> Application Management -> Configure Alternate access mappings) to use the host header (http://sharepoint.***.com) as the default mapping and the server name as the intranet access mapping. By setting the default access mapping to host headers, i noticed that Sharepoint automatically assumes that all web apps are on port 80. You can see this by going to (Central Admin -> Manage Web Applications). The port listed all 3 web apps on port 80. So I think when I was doing a profile sync and using mysites, it was messing with my AD security because of this. What I did was the following. I went to Central Admin -> Manage Service Applications -> [Name of your user profile service] -> Setup my sites. I made sure that my preferred search center had the correct port number on it (mine originally had no port number), that my my site host had a port (again no port number originally), as well as the personal site location. I then saved this.
Scenario 2: Our user profile sync had 2 BDC connections that were corrupt and throwing errors. I rebuilt the connections, remapped them to the proper user profile property.
I did both of these scenarios above around the same time. I then restarted all my servers, and at last the AD Group security is now functioning appropriately. I have done multiple IIS resets and server restarts. The issue has only reappeared once. After restarting the machine again, we were back to the AD groups functioning correctly. Because we had the issue reappear once after doing the above, I still do not feel 100% sure that either one of the above corrected the issue completely.
As long as we are up and running currently, I am moving on to other tasks with this project. My only concern that it will break again and I will have to revisit it is when we restart the servers....which is never fun. I will update as I find a "true" answer to this issue.... Let me know if any of the above helped you or if you find something I may not have thought of.
venerdì 24 febbraio 2012 10:48Just curious if the root cause was ever diagnosed, as I have exactly the same problem.....
venerdì 24 febbraio 2012 13:48
I am not a real pro, but as far as i recall Foundation does not have a synchronisation tool implemented like the Server has (which would be the User Profile Synchronisation). So you would have to add new user manualy.
- Modificato CST01 venerdì 24 febbraio 2012 13:52
mercoledì 8 agosto 2012 10:44
Have checked token-tiomeout value?
stsadm -o getproperty -propertyname token-timeout
giovedì 23 agosto 2012 13:27Did you get your query resolve ? I am getting the same problem. Did you manage to find the solution for this issue. ?
giovedì 27 settembre 2012 09:33
Edit: This was probably an issue with the people configuring the AD, so forget this:
We're having some issues too on one environment:
- AD-group is added to web application policy (given full control access)
- User belongs to the group and has access to site collection
- User is removed from the AD-group
- User still has access to site collection
Does this require user profile synchronization service to work?
- Modificato Harri K giovedì 4 ottobre 2012 05:23
giovedì 27 settembre 2012 11:46
It takes some time to refresh the contents of AD groups. I do believe in worst case scenario it can take as much as its set in token-timeout value. By default token-timeout is set for 1440 minutes.
martedì 4 dicembre 2012 14:59
The action plan is to lower the sync timeout to one minute(as example)
Run these commands:
1. stsadm -o setproperty -propertyname token-timeout -propertyvalue 1
//sets the AD group sync timeout to one minute
Then check user membership in AD group.
The membership changes should be now correctly reflected in SharePoint and group permissions correctly assigned to member user.
TechNet Reference: http://msdn.microsoft.com/en-us/library/aa543158(office.14).aspx
Questo contenuto è distribuito “as is” e non implica alcuna responsabilità da parte di Microsoft. L'azienda offre questo servizio gratuitamente, allo scopo di aiutare gli utenti e farli aumentare la conoscenza sui prodotti e le tecnologie Microsoft.