More Headaches from Vista Security
Michael Cooney writes to tell us Windows Vista may have some serious headaches in store for corporate users with third-party authentication systems like VPNs. From the article: "ISVs say rewriting their code for the new architecture will produce headaches that will extend to their customers that have deployed strong authentication such as biometrics or tokens, enterprise single sign-on and a number of other systems integrated with the Windows authentication architecture."
As expected the summary on /. is just trying to be inflammatory. The real gist of the article is as follows: Vista will require some programs to be re-written, espcially ones that interfaced closely with the old operating system. Thus many authentication systems will need to be updated. It's not really unexpected or unheard of for new APIs to break old programs. So if you want to bitch about how Vista is going to make you rewrite your code go ahead (I know I am not looking forward to it), but don't pretend it is a security problem.
Philosophy.
Sadly the DRM functions in Vista is more about making the lives of intrusive spyware easier, not harder. This is because Vista has support for drivers untouchable by the users. Microsoft calls it security, i call it rootkits built into the OS. Blizzard and the rest of the pinheads will be using Microsofts DRM to make your computer a real VIP party for everyone byt yourself.
HTTP/1.1 400
The way "Windows authentication architecture" is extended in XP is very limiting - essentially you write DLL (so called GINA) that replaces part of XP log-in system and this DLL is responsible for retrieval of users credentials for Windows. However it was possible to have only single GINA installed at the same time, so if you wanted to have two security products installed - you were in trouble.
Now Vista will support new architecture for security providers with possibility of multiple providers registered at the same time. A definite improvement for users.
In fact the new architecture is not THAT different from the previous one, so the entire article is moot. Then again, it's SlashDot...
Slashdot - free anti-Microsoft propaganda 24/7
Multiple GINA programs is fairly straightforward.
A single registry value holds what GINA to execute. If the registry value is blank, it executes MSGINA (the Microsoft default).
If you replace the GINA with a 3rd-party program (VPN, Wireless, Encryption, et cetera), then the 3rd-party is responsible for either (a) completely handling the logon, or (b) passing control to MSGINA when it is finished executing.
As a rule, this happens by your 3rd-party GINA keeping a value of its own (in the registry or INI) of what the previous GINA was. That way, if you install a new GINA, when it finishes executing, it calls whatever GINA *used* to be in the default registry location.
First you have MSGINA.
You install ENCRYPT-GINA.
ENCRYPT-GINA executes and calls MSGINA.
Then you install VPN-GINA.
VPN-GINA sees ENCRYPT-GINA as the GINA to execute when complete.
VPN-GINA executes and calls ENCRYPT-GINA
ENCRYPT-GINA keps its own value for what to call next and calls MSGINA.
Add all the GINAs you want.
It's true that *some* GINAs don't play nicely, or won't always execute if a certain GINA has executed before it (or comes after it) - but for the most part it works.
The only REAL problem is when a GINA is stupid enough to place itself incorrectly in the chain -- which can leave a machine executing GINAs in a loop...and Windows is smart enough to restore MSGINA when that happens anyway.
It's not "a good thing" when they change how database connection pooling works.
It used to be recommended practice to stick the db connection in the session object at session.start.
Option Pack 4 changed this behaviour. But it didn't show up until the websites you had already deployed started to get "un-reproducable" errors. The unpooled connections hung around for 30 mins after the last request for that session. Once the site got enough traffic it started killing the application. Could be 6 months, could be a year. Took a while to work that one out, much to the annoyance of my customers, and at my expense "you wrote it, it must be a bug in your code, bug fixes are covered in our agreement". Getting off the MSDN treadmill was glorious.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter