Team Foundation Server could not resolve the user or group
One of my recent tasks was to setup a TFS 2008 server and migrate our VSS system across to it. Once done, set up the projects and users. Well, since I have a good knowledge of the systems and had done a TFS 2005 deployment previously (though it was not adopted), I felt confident that the install wouldn’t be an issue. I did the usual prep—reading blogs and learning from others—and that helped me avoid some pitfalls.
Next up was the migration of VSS to TFS, which was actually not a major requirement—it was just there for legacy projects. All active projects would have to check their code into new TFS projects, the ones we planned to create in TFS. The key benefit of this was that it would allow us to align with EPM better than the migration tool would have allowed.
I created a project, and imported the 1.7 GB of source code into it! It took some time. Then I needed to add the users, and this is where I met a problem. Regardless of whether I used the command line, the TFS admin tool, or the GUI, I kept getting an error: Team Foundation Server could not resolve the user or group. <AD Distinguished Name of the User>. The user or group might be a member of a different domain, or the server might not have access to that domain. Verify the domain membership of the server and any domain trusts.
The AD issue and TFS issue both revolved around the fact that in our AD, the Authenticated Users (AuthUsers) group did not have read permissions to our users and the containers they were in. This is odd to an outsider because, when AD is set up, the AuthUsers group does have permissions—so why would ours be different, and what are the implications of changing it?
The reason there is a difference is because our AD was set up according to Hosted Messaging and Collaboration (you can read more about it here), which specifically removes the AuthUsers group permissions for security reasons (i.e., to prevent users from seeing other customers). Because of this change, the GPO could not access the users’ accounts, nor could TFS read from AD what it needed.
To solve this for TFS, it meant giving AuthUsers read permissions to the users who needed to access TFS and their immediate container. For AD/GPO, it required just AuthUsers to have permissions on the container for the users (it doesn’t need permissions on the actual users) and all of its parent containers. Once those were done, the group policies and TFS started to work 100%. That’s great—but what is the impact on the hosted environment, and is this the best way to solve the issue?
Well, this does open up a security risk: customers could see other customers, simply by logging into the domain. For us, this is mitigated as we aren’t offering hosted TFS; this is just for our own internal staff, who are aware of who our customers are, and we aren’t worried if our customers know about our staff. It’s also very difficult for a customer to see other customers, as most applications don’t allow it, and those that do—such as MSCRM—ignore it in an HMC environment in their standard configurations.
In regards to whether this is the best way to solve the issue, my view is that it isn’t. Instead, you should run a separate AD for each customer, this being a normal AD system which runs at the client premises. Using the Customer Integration component of HMC (which is based on MIIS), you sync the customer AD to the hosted AD. This means you could run GPOs and TFS on the customer site without the need to change anything in a hosted way.