TeamBuild – Error – Failure: unknown user name or bad password

This particular error can be a pain in the ass to track down, and it will cause Team Build to be unable to create the drop directory. But there are only really two causes for it.

1) You will generally start seeing this error after a problem occurs with a build machine that causes you to recreate the drop location (meaning, it’s the only time I have seen it). Or something dealing with you remaking the drop location.
2) It can also come up with cross-domain development environments.

If you think you are experiencing problem #1
1) check whether the same same build agent for all the builds
2) check whether instead of an alias to refer to the machine you can use the IP

If you think you are experiencing problem #2

1) 9 times out of 10 this is a domain trust problem. Simply put, a TFS user domain doesn’t trust the TFSService account, thus when users are added the TFSService account doesn’t have the read permission on the domain controller. So you can either implement the domain trust or change the TFSService account to use the other domain.


The Basics of Claims – Part 5 – The Making of a Good Claim

There is plenty of information that may be stored within security tokens. This can include the name of the user, their email address, the email of their manager, and anything else that you would like to use for identification purposes. It is a good idea to consider claims as being just like the various elements of Active Directory and that you will have minimal control over them. It can be hard to centralize too much information when it comes to users or to issue claims with that type of information for applications.

There are many different types of claims out there that you can issue. You will need to discuss extending the Active Directory set up with your IT department. They will likely only do so if there is a justifiable reason to do so. Often, they already have what is necessary in place so they won’t be making changes to it. You don’t want to have centralized data that is specific to only one particular application though.

What you will find is that applications relying upon claims are able to benefit from a table that stores information about users on it. This is where the application specific user information will be. The other applications out there really aren’t even going to care about this at all. This is the data that you have authority for with a given application. That is the single source for the data to be stored. What is important is that there is someone in place to keep it all current for you.

You can also use such a table to cache data that isn’t authoritive in nature. You will get this information from claims. You may want to cache an email claim for every user so that you are able to send out notification emails without the user having to log in first. You want your cached claims to be in a read only format. You also want to make sure they are refreshed each time a sure visits that application.

You don’t need much to make claims good as a little bit of it will go a very long way. You need a good claim to go hand and hand with an issuer that is able to provide you with user information, to make the authorizations, and to customize the applications just the way you want them.

Once the user has been authenticated, the issuer will create a claim about them and issue a security token. ADFS has roles in place that allow the LDAP materials from the user record that is in the Active Directory. There can also be rules in the SQL statements so that you will be able to access user data. You can also add other stores which is a good idea as many companies out there have an identify that is fragmented in some way. With ADFS though it is hidden so the claims based application won’t be broken if you need to move the data around. The applications aren’t tied tightly to identity which is a huge benefit of claims based identity.

With claims based applications you can decide if you would like to make the users anonymous or not. Since there isn’t an application directly authenticating the users this is possible. This can be a feature you decide to use but you can’t make any claims that will personally reflect on a user. Some issuers out there encourage the idea of private user identification. That way an anonymous identifier that is unique in nature can be used with claims based identity.


Ten Part SharePoint Claims Based Authentication Series

I went ahead and continued to expand the claims based authentication archive on the site with 10 more CBA articles.

So, inclusive of the following Understanding SharePoint Claims Based Authentication series posted two weeks ago:

Expanding on this, I built another series that deals with SharePoint claims based architectures more exhaustively: