Tags: groups, microsoft, msdn, running, security, server, services, setup, sharepoint, software, windows
Sharepoint Services 3.0 and AD Security Groups?
I am running Sharepoint Services 3.0 on a Windows 2003 R2 Server. Everything setup without issue and works without issue. I can add AD security groups to Sharepoint groups and the users get access. However the only security groups that actually grant access are the groups that were there prior to the Sharepoint install. Any groups that were created after the install or changes to those groups are not granted access in Sharepoint.
Basically I add a presharepoint ad security group to a sharepoint group for access and it works beautifully. I create a new group, add a user to it, and add it to the sharepoint group - it adds without issue but does not grant access to the site. I even tried creating the group, adding it to the site and letting it sit overnight thinking it was some time of replication or job import from sharepoint (just a thought), but that didn't work either. I tried restarting the WSS services, I even rebooted the server with no luck.
Anybody else experiencing this or did I miss something someplace? I reproduced the same error today on a fresh install of sharepoint services 3.0 on another server. Any help would appreciated.
Leave a comment...
- 9 Comments
Well the group I created yesterday and have been testing this process with finally allowed access to the sharepoint. It took 24 hours for the group change to take effect. Is there anyway to force this? It is like the server reads AD once every 24 hours and caches the credential information. And to further prove that theory I went back and removed the user from group and I was still able to access the server.#1; Tue, 04 Sep 2007 14:26:00 GMT
- Sharepoint needs to pull in the new groups into it's DB "profile import". This is done every x hours...I am not sure of the default. You can go into the sharepoint site administrator and change this schedule....or run it manually. i think it is the "profile database" settings where you change this.#2; Tue, 04 Sep 2007 14:27:00 GMT
- Thanks for the response. I have looked all over the site administrator for anything that pertains to that but I can't find anything. Is this an option that is just hard coded into WSS 3.0 and is a feature that you can actually adjust if you are running the full Sharepoint Server 2007? Just curious because I can't find it anywhere. Thanks for any more information you can provide.#3; Tue, 04 Sep 2007 14:28:00 GMT
MOSS has the profile import, etc...
WSS is using the groups as well but it is mysteriously caching it from what has been explained.
I am sure that there is a service that runs and if there is a service, there is a configuration for it.. though I don't know where... I'll dig into it and see what I can uncover.#4; Tue, 04 Sep 2007 14:29:00 GMT
- I has to do with the way the computer reads DC objects. If you want the effects of a new group created imediately in a DC path the computer has already accessed you need to reboot. There is no way that I know of to force user/group membership with out a log off for the user or a reboot for the computer until the permission structure is recached. Profile import has nothing to do with this.#5; Tue, 04 Sep 2007 14:30:00 GMT
I think baba is on to something... When the credentials are gotten from the Domain Controller upon logon, they are cached for a period of time. The Auth Token (Kerberos Token) has a list of the users group memberships in the token so that you don't kill your dc's , etc.. with excessive queires for group membership.
This means that if someone has already logged in and you change the group membership afterwards, this is not immediately reflected in the logon token.
Hope that helps.#6; Tue, 04 Sep 2007 14:31:00 GMT
Well to answer some of the questions here......
I have tried several things here to get this to force thru the system:
I made a group change to a user, added the particular group to the contributor group, and the user could not access the site. I forced replication throughout the domain so that the same group change would be available on all DC's. I attempted a GPUPDATE /FORCE on both the PC and the sharepoint server. Tried to access the site, still can't. Next I rebooted both the server and the PC that I was testing from. Still couldn't access the site.
Now if I added a group that the user had already been part of I was able to access the site immediately. The only time that the new group worked was when I left it in place for approximately 24 hours and then the new group worked. I also tested the removal of a user in the same way and the user could still access the sharepoint site for approximately 24 hours until the sharepoint server updated its group membership.
So yes I agree with everybody that the credentials are cached but it appears from my testing that they are cached in the sharepoint server and only update approximately every 24 hours.#7; Tue, 04 Sep 2007 14:32:00 GMT
- I had the exact same issue here (Thanks for the excellent description!). I used your post with Microsoft Support. Since we are using MOSS, Support required/walked us through setting up the SharedServiceProvider. This fixed the problem. Updates to AD Groups are reflected within seconds in Sharepoint.
I tried to get Support to answer the question for those that do not own MOSS and are using a WSS install only (since this seems to be a WSS issue), but was not able to successfully get an answer. I am guessing they are going to market that as a buy up feature.#8; Tue, 04 Sep 2007 14:33:00 GMT
- That is the conclusion that I came to also. It is one of those perks by purchasing the full version server. I guess they have to add some things to justify purchasing it. I appreciate you confirming this. Thanks.#9; Tue, 04 Sep 2007 14:34:00 GMT