AliGrant.com
 
Valid XHTML 1.0!

Valid CSS!

Powered by PHP

Get FireFox

1&1 Internet


Archived News

IIS Integration Authentication optionsTuesday 20th July 2010
Argh, it's a pain, and there are a million pages on it on the Interweb.

I'm approaching from the direction of getting BizTalk's BAM Portal working. Hurdle one, it will only run on 32-bit IIS servers, which means it can't run on our BizTalk hosts (as they are in 64-bit mode). So we plonked it on our Intranet server.

Next authentication. You need to use the BizTalk configuration tool to setup the portal unless you want to hack about. It encrypts logon details into the registry based on the service account used in the setup.

In order to access BAM, you need to use Integrated Authentication in IIS to allow users to authenticate correctly. This boils down to three options:

- Kerberos
- NTLM
- Plain-text

Kerberos is a pain because you need to make sure all the AppPools on the server are all running under the same identity (e.g. A service account for that server). You then need to manuall assign a "SPN" in Active Directory for this AppPool's service account.

This is due to the DC encrypting tokens with the IIS server's password, and it needs to know which password to pick if there are multiple AppPool identities (Network and Local Service accounts are normally ok, but can't be configured with BAM).

NTLM is a pain because it doesn't allow you to "double-hop", so if you have anything that needs to pass through the user's authentication details it won't work. Kerberos allows this. Kerberos also requires a bit of a fiddle with non-IE browsers, where NTLM is widely supported.

The final option is plain-text, but this is horrible too as your NT passwords get dumped around your network in the clear. Unless of course you use SSL. This also allows for double-hop as the IIS server gets a copy of your password (to it, essentially in the clear).

But do you trust your password to an IIS server?


32-bit .NET apps on x64Saturday 10th July 2010
I've just wiped my old Windows Mobile phone and given it a fresh install. Along with the phone came a copy of CoPilot 7. Handy Sat Nav program, which I often use (even just for the speed camera alerts).

But this is where things went wrong. I installed CoPilot Central (version 1), which is the PC bit of the software required to load the maps etc onto the device. And it completely failed to run. No amount of Windows troubleshooting compatibility helped here.

A quick nose shows that it's a .NET application (tell tell signs of manifests and config files). So trawl through my Windows log to try and find the error. System.BadImageFormatException

Ah yes, well this is going to be done to my computer being 64-bit, and this software being old. Although this shouldn't matter in .NET as it's not platform specific.

The reason for this is down to developers not setting the flags correctly when compiling. Lucky for us Microsoft have a too called CorFlags.exel that allows us to fix this without having to compile the app ourselves.

This is available as a part of the .NET SDK.

Simple run the following command:
corflags "CoPilot Central.exe" /32bit+

Job done, the app should now launch as normal.


SQL SIDsTuesday 6th July 2010
I accidentally deleted a security group out of AD that was being used as a SQL 2005 login - oops. So I recreated it and added the members back in.

Problem is, this didn't fix my login issues. So I deleted the server login and recreated it. But then I couldn't link the new server login to the existing database logins. Nuts!

As we know from moving databases back in the old days, we can use "sp_change_users_login". Alas, this proc does not work with windows/domain principles/logins. Double drat!

Providing you have SP2 you can use the ALTER USER WITH LOGIN statement to repair.

You will need to delete the server login and re-add it, then run this statement against each database you want to re-link:

ALTER USER [MYDOMAIN\mygroup] WITH LOGIN=[MYDOMAIN\mygroup]

The other easy option is just to go home an ignore it. I found that the servers that I hadn't got round to fixing figured themselves out the following day - sitting around 15 minutes for replication and a restart didn't appear to be enough (being the first thing I tried).


Previous Next