Windows Groups - TFS does not see new users until restart
If using Windows groups, it appears that there is a bug in VSTS.TFS seems to query the Windows Security system once for a list of users belonging to each group.When you add a new user to the Windows Group, TFS doesn’t get the update – i.e. it’s out of date. The result is that you won’t be authenticated if you added yourself tp a Windows group after TFS has queried the Windows security system.
To reproduce :
Using a TFS Admin account, perform the following:
Create a local Windows Security Group named ProjectAdmins
To this group, add a user account e.g. User01
In TFS, under Project Settings, Group Membership, add the Windows Group, ProjectAdmins to one of your Team Project Administrator security groups.
Log on to TFS from another computer, using the credentials for user01 you added to ProjectAdmins. User01 will be a local user on the remote workstation.
You will be denied access.
If you restart Team Foundation Server, the update will be effected from Windows Security to Team Foundation Server, and the user will be able to authenticate on TFS.
I hope MS can take a look at this one. It can be nasty if you are using Windows Groups to manage TFS Security.
If you wait, TFS will pick up the change.
TFS does query the Windows Security system when starting up, but that is not the only time that it is done. There are two ways that a refresh is triggered. The first is whenever a change happens to group membership through the TFS Group Security Service (GSS) interfaces (add/delete users/groups). In this case, TFS has a direct signal that a refresh is required and so kicks off processing immediately. When users are added outside of TFS, as they are in Active Directory or local Windows groups, the change is picked up by a synchronization process that runs on a schedule. The default processing interval is 1 hour. The frequency of the update can be changed by adding a TimeSpan string to the TFS Services web.config to override the default IdentityUpdatePeriod of "1:0:0".
A cheap way of forcing an update if you do not want to wait for the default processing interval to expire would be to create a new TFS group and then delete it, or perform some other TFS-visible operation on groups.
Thanks, Bill.
Why did you choose this architecture? Why does TFS keep its own copy of the Windows Users/Groups? I suppose it's a performance decision not to delegate the authentication to Windows every time.
The primary reason is that we did not want to force admins to create AD groups to manage TFS users. That is a requirement that has driven the creation of similar user and group management systems in many other applications (e.g., SharePoint, SQL). The direct exposure to AD query performance was also a consideration.
OK. Thanks for your replies.
Is there a tool or any behaviour in the object model to perform this refreshment?
There is no easy way to force the sync to happen short of doing an iisreset.
Had this exact problem, and the answers above were close: but the key for us was we had to remove the group in question and add it again. Adding a random group didn't work.
M@
That is right... I've learned that we only sync the groups that change since posting the original suggestion to just show a change of any sort to GSS to force the sync.
I am having the same issue and the ONLY way to resolve this is to remove and re-add the AD group.
Can somebody please let me know how i can verify that the sync process is running every 1 hour and how i can update that do something like 15 minutes?
I think that entry should be in C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Services\web.config, but i am not seeing it. I am also seeing some exceptions in the eventlog that look like we are have sync issues.
HELP!
Geno
You can determine the last time that group membership information was changed as follows:
- Open IE on the TFS AT and browse to http://<server>:8080/services/v1.0/serverstatus.asmx
- Invoke the GetServerStatus method
The LastIdentityChanged timestamp will tell you the last time that a user was added to the system - either directly or through synchronization with AD.
You are right... the IdentityUpdatePeriod key needs to be added to the services\web.config file. It is not there by default so you will have to introduce the key into appSettings.
Are you sure of "IdentityUpdatePeriod" and its format? Google this keyword and "this thread" is the only place on the net were it is mentioned.
I have a sandbox TFS and added the following:
<appSettings>
<add key="IdentityUpdatePeriod" value="0:1:0"/>
By Checking http://localhost:8080/services/v1.0/serverstatus.asmx/GetServerStatus
My response shows:
<ArrayOfDataChanged ...>
- <DataChanged>
<DataType>LastAclChange</DataType>
<LastModified>2006-08-08T20:32:28.487</LastModified>
</DataChanged>
- <DataChanged>
<DataType>LastIdentityChange</DataType>
<LastModified>2006-08-08T19:04:25.7</LastModified>
</DataChanged>
</ArrayOfDataChanged>
It did not change after many minutes. After making a AD Group change and making sure it had replicated, I added a User to a TFS group. The GetServerStatus then showed:
<ArrayOfDataChanged ...>
- <DataChanged>
<DataType>LastAclChange</DataType>
<LastModified>2006-08-08T21:20:22.217</LastModified>
</DataChanged>
- <DataChanged>
<DataType>LastIdentityChange</DataType>
<LastModified>2006-08-08T19:04:25.7</LastModified>
</DataChanged>
</ArrayOfDataChanged>
NOTE! It's the LastAclChange value that changed. Examining the properties of the AD Group from within TFS showed that TFS had not updated the member list.
Removing THIS group and adding it back caused its membership to be updated. During all of this, LastIdentityChange remained the same.
I have no idea how long it takes to propagate a change on its own. If I get any more info I'll post it.
As of now, this means we must manually remove and add Groups in TFS as a part of our AD group management... I'd rather not.
Cash
I'm seeing similar behavior as cashfoley. If anyone can provide further information on whether this thread has solved the problem or not, I'd greatly appreciate it. Details would be even better.
Thx,
Ricky
It's strange to type, but the "IdentityUpdatePeriod" will not affect the 2nd sync with Active Directory. The 1st sync is triggered immediately after the application starts. The IdentityUpdatePeriod will affect when the timer wakes up, but not when it starts(which triggers the 2nd sync). You can set the timer start by setting the "IdentityUpdateInitial" app key.
<add key="IdentityUpdateInitial" value="0:1:0"/>
LastIdentityChange did not work in V1 and has subsequently been removed. It will only report when TFS Application groups are created, deleted, or renamed.
You can look up the last identity changes from the database directly as a workaround (this will return the top 10):
select
top 10 last_update, display_name, domain, account_name from
TfsIntegration.dbo.tbl_security_identity_cache order
by last_update desc
I forgot to mention that IdentityUpdateInitial defaults to 1 hour.
