Fighting the machine

So far, HAM is very fun.

My first radio contact, Michel VE2CYS was very pleasant. It also was a bit of a learning curve me for. I'm not used to memorizing call signs on the fly while trying to remember what the phonetic alphabet is for my own.

My VA2KSM call-sign has finally been approved, time to start pushing the PTT button on the radio now.

Damn, I'm just floating!

It's with great pleasure that I'm announcing that I passed my HAM test Saturday and am now awaiting the confirmation from Industry Canada and RAQI to see if my call-sign request is approved. (VA2KSM)

This is perfect, even more so since I found my 2m/70cm handheld that I thought that I had lost. Life can be sweet sometimes, today is a good day.

Now, all I need is to get myself a magnetic antenna for the car and I should be all set.

Next year, I'd love to stock up on a few parts and try and sell them - could be interesting if I can get a low price and sell them for say 75% of the prices that I saw there Saturday.

After I installed Visual Studio 2008 SP1 on my TFS box (which is also my build box) I had this particular error whenever I would try to connect from the TFS client in Studio (I couldn't connection from anywhere else either for that fact)

TFS30059: Fatal error while initializing web service

Contrary to some earlier TFS 2008 SP1 posts, this had nothing to do with SQL databases left in single-user mode or the web security being in DENY mode.

All I had to do was install(re) TFS 2008 sp1 on the server and restart it.

Dime Casts also published some LINQPad videos, you can find them here:

DimeCasts.Net Episodes for LinqPad (5)

Here's  a link to a very interesting Tutorial on how to use LINQPad, this little product is incredible when it comes to learning and testing LINQ queries before you drop them in VS2008.

Enjoy,

Webinar: Writing LINQ Queries with LINQPad

What do you need on the Build server in order to run tests?

We are talking about the Build server here folks, not the TFS server. Unless you use the TFS box as a build server as well.

In Visual Studio 2005, you have to install the Tester or Suite product to perform post-build tests

In Visual Studio 2008, you have to install either the Developer or again the Suite product.

Thanks Maor,

Coding mixture: Running Tests On TFS Build Machine

This is a nice little spin of a problem, one that actually got my neurons firing for a few hours.

If you are familiar with ASP.NET applications, you will know that when you use windows authentication like this:

<authentication mode="Windows" />

The username that you will be getting from the IIDentity interface by say using this:

HttpContext.Current.User.Identity.Name

Will not return [username] but instead will return [domain]\[username] instead.
For example, in my case if my login is KARELL then calling

HttpContext.Current.User.Identity.Name

Will return DOMAIN\KARELL and not just KARELL when i'm in Windows Authentication mode.

This is a small problem when you need to talk to Active Directory to get the complete information of a user. Active Directory stores an attribute called sAMAccountName (watch the case sensitivity here).

So, in a simple world, you could query AD with the following query and get the System.DirectoryServices.DirectoryEntry object by say using the following LDAP query and strip the "DOMAIN\" part of the username:

(&(objectcategory=person)(sAMAccountName={0})(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Which will return in theory a single object as a result. However what do you do if you have more than one domain where the Usernames can repeat?

DOMAIN\KARELL is not the same person as DOMAINE\KARELL.

Hence comes a few other objects:

System.Security.Principal.NTAccount and also System.security.Principal.SecurityIdentifier which are very useful classes.

Did you know that you can ask an AD GC or DC to give you a single user DirectoryEntry simply by passing the SecurityIdentifier of the user?

Here's how it's done:

First, you get the SecurityIdentifier (SID) of the User by using their username in the form of [DOMAIN]\[USERNAME]

SecurityIdentifier sid = (SecurityIdentifier)account.Translate(typeof(SecurityIdentifier));

Then, the trick is simply to pass this information to AD in order to get a DirectoryEntry object back:

const string SidSearchFormat = "LDAP://<SID={0}>";
DirectoryEntry userEntry = new DirectoryEntry(string.Format(SidSearchFormat, sid.Value));

That's it! You now have a DirectoryEntry object hat has all of the information of the user. You can check the properties, get the user's full name from ActiveDirectory and put it up on the ASP.NET UI and look good.

You can also do the reverse, you can, from an ActiveDirectory search perform the reverse. Simply make sure that you ask for the objectSid when you query ActiveDirectory, like such:

deDirEntry = new DirectoryEntry(connectionstring, this._username, this._password, AuthenticationTypes.Secure);

DirectorySearcher mySearcher = new DirectorySearcher(deDirEntry);
mySearcher.PropertiesToLoad.Add("givenName");
mySearcher.PropertiesToLoad.Add("sn");
mySearcher.PropertiesToLoad.Add("initials");
mySearcher.PropertiesToLoad.Add("sAMAccountName");
mySearcher.PropertiesToLoad.Add("mail");
mySearcher.PropertiesToLoad.Add("objectSid");

and you can then do the following to transform the objectSid (SID) back to a username and know which domain your user is from and not get mixed up with another user

byte[] sid1 = (byte[])Properties["objectSid"][0];
SecurityIdentifier sid = new SecurityIdentifier(sid1, 0);
NTAccount account = (NTAccount)sid.Translate(typeof(NTAccount));
Username = account.Value;

If you have any questions or thoughts, you can either e-mail me or leave me a comment.