locked
Windows Groups - TFS does not see new users until restart

    Question

  •  

    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.

    Friday, April 21, 2006 1:49 PM

Answers

  • 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.

    Friday, April 21, 2006 3:23 PM

All replies

  • 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.

    Friday, April 21, 2006 3:23 PM
  • 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.

     

    Saturday, April 22, 2006 6:04 PM
  • 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.
    Thursday, April 27, 2006 10:07 PM
  • OK.  Thanks for your replies.

     

    Friday, April 28, 2006 5:01 AM
  • Is there a tool or any behaviour in the object model to perform this refreshment?
    Wednesday, May 3, 2006 2:32 PM
  • There is no easy way to force the sync to happen short of doing an iisreset.
    Friday, May 5, 2006 1:45 PM
  • 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@
    Friday, May 19, 2006 3:19 PM
  • 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.
    Thursday, June 1, 2006 8:27 PM
  • 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

     

     

     

    Tuesday, June 27, 2006 7:20 PM
  • You can determine the last time that group membership information was changed as follows:

    1. Open IE on the TFS AT and browse to http://<server>:8080/services/v1.0/serverstatus.asmx
    2. 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.

    Thursday, June 29, 2006 5:03 PM
  • 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

    Wednesday, August 9, 2006 1:52 AM
  • 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

    Tuesday, August 15, 2006 3:55 PM
  • 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

    Friday, September 8, 2006 6:23 PM
    Moderator
  • I forgot to mention that IdentityUpdateInitial defaults to 1 hour.
    Friday, September 8, 2006 6:29 PM
    Moderator
  • Thanks Sam (and Bill),

    I know I can figure it out by trial and error, but the value of "0:1:0" is one minute?

    Seeing how if you Google "IdentityUpdateInitial", this thread is the only place it is mentioned on the net!  We might as well have good documentation.  ;)

    Cash

    Monday, September 11, 2006 12:33 AM
  • Hi,

     we have here an installation of TFS with ~30 Team Projects and ~300 Users, with a few AD Function Groups. The AD itself seems pretty large. If we add a user to an AD group it takes up to two days until TFS picks the user up!? The server is pre SP1.  

    Any ideas? Is this fixed in SP1 or Orcas?

     

    Kind regards,

     

    Markus

    Wednesday, March 28, 2007 3:38 PM
  •  

    Hi All,

     

    There is a known issue:

    7.8 Team Foundation Server may not automatically synchronize permissions with Windows Server 2003 on the configured interval.

     

    See details in http://msdn2.microsoft.com/en-us/teamsystem/aa948855.aspx

     

    The solution is to recycle TFSAppPool. It worked for me. But this will cause users to be kicked out from TFS. They will have to reconnect using their clients again.

     

    Instructions as Per MSDN article:

     

    "

    7.8 Team Foundation Server may not automatically synchronize permissions with Windows Server 2003 on the configured interval.

    Details: In some cases, the Team Foundation Server does not synchronize with Active Directory or Windows Users and Groups. The hourly background synchronization does not work.

    Workaround: A full synchronization will occur if one of the following takes place:

    • You manually recycle the TFSAppPool using the Internet Information Services Management Console by following these steps:
      1. Click Start, click Administrative Tools, and then select Internet Information Services (IIS) Manager.
      2. In the Internet Information Services (IIS) Manager window, expand the node that has the name of the computer where you installed Team Foundation Server.
      3. Expand the Application Pools folder.
      4. Right-click TFSAppPool and selectRecycle.
    • You restart the application tier.

    A partial synchronization will occur when you add an Active Directory group to a Team Foundation Server group. Only the Active Directory group and its subgroups and members will be synchronized with Team Foundation Server.

     

    "

    Tuesday, March 18, 2008 10:28 AM
  • If you have access to the AT, a straightforward way to monitor background sync with Active Directory is from the event logs. The start and finish of the periodic background sync is marked by the following logs:

     

    TF200028: Team Foundation Server started group synchronization. Group synchronization started with the Team Foundation Valid Users group.

     

    TF200030: Team Foundation Server completed group synchronization for the following group: Team Foundation Valid Users.

    If you do not see these, then something is not occuring as per design. When a sync is triggered manually by adding a group to TFS (may even be an existing group), you will see similar logs, except that "Team Foundation Valid Users" will be replaced by the group in question, and the log will indicate that it was manually triggered.

     

    Vasu

     

    Friday, March 21, 2008 12:43 PM
  • I had this problem and I "solved" it with removing and adding the group to the project collection permission. In this way it'll update instantly.

    Wednesday, April 17, 2013 8:50 AM