Over on the Ask the Directory Services Team blog on TechNet they have a good post on a few wiki entries for dealing with ADFS and troubleshooting.
One of the problems with pushing all this data back and forth between Token Services
and clients and Relying Parties is that some of this information really needs to encrypted.
If someone can eavesdrop on your communications and catch your token authorization
they could easily impersonate you. We don’t want that. As such, we use
certificates in ADFS for EVERYTHING.
The problem with doing things this way is that certificates are a pain in the neck.
With ADFS we need at least three certificates for each server:
-
Service Communication certificate: This certificate is used for SSL
communications for web services and connections between proxies. This is the
certificate used by IIS for the Federation Service site.
-
Token Signing certificate: This certificate is used to sign all tokens
passed to the client.
-
Token decryption certificate: This certificate is used for decrypting
incoming tokens. This would be the private key for the Service Communication
certificate.
Managing these certificates isn’t easy. Sometimes we can get away with just
using our domain CA, other times we need 3rd party CA’s to sign them. Microsoft
has provided lots of guidance in this, but it’s not the easiest to find. You
can access it on TechNet (Certificate Requirements for Federation Servers): http://technet.microsoft.com/en-ca/library/dd807040(WS.10).aspx
Hopefully that helps.
WinFS has been puttering around my idle thoughts lately.
Yep, weird.
Why is it still available on MSDN and TechNet subscriptions?
Food for thought.
Tonight at the IT Pro Toronto we did a pre-launch
of the Infrastructure 2010 project.
Have you ever been in a position where you just don’t have a clear grasp of a concept
or design? It’s not fun. As a result, CIPS
Toronto, IT Pro Toronto, and TorontoSQL banded
together to create a massive event to help make things a little more clear.
To give you a clearer understanding of how corporate networks work. Perhaps
to explain why some decisions are made, and why in retrospect, some are bad decisions.
Infrastructure 2010 is about teaching you everything there is to know about a state-of-the-art,
best practices compliant, corporate intranet. We will build, from the ground
up, an entire infrastructure. We will teach you how to build, from the ground
up, an entire infrastructure.
Sessions are minimum 300 level, and content-rich. Therefore:
Well, maybe. (P.S. if you work for Microsoft, pretend you didn’t see that picture)
This post has had a few false starts. It’s a tough topic to cover, as it’s a
very controversial subject for most people still. Hopefully we can enlighten
some people along the way.
From a high level perspective, the UAC was developed to protect the user without necessarily
removing administrative privileges. Any change to the system required a second
validation. On older versions of Windows, an application running with administrative
credentials could change any setting on the box. Viruses and malware became
rampant because of this openness, given that the average user had administrative credentials.
Most average users balked at the idea of having a limited user account, so Microsoft
came up with an alternative for the new OS, Vista – a second form of validation.
You told the computer you wanted to make a change, it asked “are you sure?”
Logically it makes sense. Consider an instance where a devious application wanted
to change some setting, and because Windows wanted to verify it’s ok to make this
change it asked “are you sure?” If you responded no, the change didn’t happen.
Simple enough. However, here we start running into issues. There are three
perspectives to look at.
First, the end user. Simple changes to basic settings required validation.
This annoyed most of them, if not all of them. They didn’t care why it was asking,
they just wanted to delete shortcuts from their start menu. Their reaction:
turn off UAC. Bad idea, but security loses when it comes to usability in the
case of the end user.
Second, the irate IT Pro/Developer. Most people working in IT make changes to
system settings constantly. Given that, the UAC would be seen many times in
a day and it would, for lack of a better word, piss that person off. They didn’t
care what security it provided, it was a “stupid-useless-design” that shouldn’t have
been created. Their reaction: turn off UAC. Once again security loses
when it comes to usability.
Third, the knowledgeable IT Pro/Developer. Not a lot of people fell into this
category. However, these tended to be the same type of people who fit into the Lazy
Admin category as well. When managed properly UAC wasn’t all that annoying
because it wasn’t seen all that often. Set-it-and-forget-it and you don’t ever
see the prompt. If you created the system image properly, you don’t have to
constantly keep changing settings. It’s a simple enough idea.
But…
Application compatibility is a pain. Most applications didn’t understand the
UAC, so they weren’t running with a validation and generally broke when they tried
to do things they really shouldn’t be doing in the first place. These are things
like manipulating registry keys that don’t belong to them, writing to system folders,
reading data from low-level system API’s etc. This was reason #1 for disabling
UAC.
And now…
With the general availability of Windows 7 in about 2.5 hours from now, it seems like
a good time to discuss certain changes to UAC in the latest version of Windows.
The biggest of course being when Windows decides to check for validation.
Windows 7 introduces two new levels of the UAC. In Vista there was Validate
Everything or Off. Windows 7 added “Do Not Notify Me When I Make Changes to
Windows Settings”. This comes into effect when the user makes a change to a
Windows setting like display resolution. Windows is smart enough to realize
it’s the user making the change, and allows it. It’s second additional level
is the same as the first, except it doesn’t hide the desktop.
Now we get into some fun questions.
-
How does Window’s know to not show the prompt? It’s fairly straightforward.
All Window’s executables that were released as part of the OS are signed with a certificate.
All executables signed with this certificate are allowed to run if user started.
This is only true for Window’s settings though. You cannot implement this with
3rd party applications. There is no auto-allow list.
-
How does Window’s know it’s a user starting the application? Lots of applications
can mimic mouse movements or keyboard commands, but they occur at a higher application
level than an actual mouse move. Input devices like mice and keyboards have
an extremely low level driver, and only commands coming from these drivers are interpreted
as user input. You cannot spoof these commands.
-
Can you spoof mouse/keyboard input to accept the UAC request? No. The
UAC prompt is created in a separate Windows desktop. Other well known desktops
include the Locked screen, login screen, and the Cardspace admin application.
No application can cross these desktops, so an application running in your personal
desktop cannot push commands into the UAC desktop.
Mark Russinovich has an excellent article in TechNet
Magazine that goes into more detail about changes to the UAC. Hopefully
this post at least covered all sides of the UAC debate.
As budgets get tighter, Tech·Days is the perfect way to get the Tech·Ed experience
without the travel expense, with two days of skill-strengthening education to help
you position yourself for success by:
-
Learning the technology—with a customizable agenda from over forty
sessions across five technical tracks on both current technologies and new products,
like Windows® 7 and Microsoft® Exchange 2010;
-
Connecting with Experts and Peers—with Birds-of-a-Feather lunches
and the new Windows 7 Zone, you'll have lots of opportunities to share your ideas
with those who know the products best; and
-
Apply what you learn—with a Learning Kit packed with products and
resources so you can continue to grow your skills long after the event has finished.
Technologies discussed: Windows 7 Operating System, Windows Server®
2008 R2 operating system, Visual Studio® 2008 development system, Silverlight™ browser
plug-in, Exchange 2010, Security/Management, and more.
If you want the VIP Discount use the promo code TD09Partner.
City |
Date |
Venue |
VANCOUVER
TD09Partner |
SEPTEMBER 14-15
|
Vancouver Convention Centre |
TORONTO
TD09Partner |
SEPTEMBER 29-30
|
Metro Toronto Convention Centre
|
HALIFAX
TD09Partner |
NOVEMBER 2-3
|
World Trade & Convention Centre
|
CALGARY
TD09Partner |
NOVEMBER 17-18
|
Calgary Stampede
|
MONTREAL
TD09Partner |
DECEMBER 2-3
|
Mont-Royal Centre |
OTTAWA
TD09Partner |
DECEMBER 9-10
|
Hampton Inn & Convention Centre
|
WINNIPEG
TD09Partner |
DECEMBER 15-16 |
Winnipeg Convention Centre
|
Early Bird: $299, Regular Price: $599
There is a good chance I will be presenting at one (or more) of these locations, so
keep an eye out. In the event that I don’t, I will definitely be enjoying the
Toronto stop of the tour. In either case, I will be there ready to learn, with
a pocket-full of business cards.
Oh, and I’ll be leaving with a box/bag/shopping cart* of swag.
*Metaphorical shopping cart. They are going to give away lots of
awesome stuff.
Alright, so you've just implemented Transparent Data Encryption on your database.
Your database is extremely secure. The data, not so much. You see, the
problem is this: the data travels unencrypted between SQL Server and your application.
Whoops.
To enable SSL Encryption on the server side, there are a couple of fairly simple
steps involved:
-
In SQL Server Configuration Manager, expand SQL Server Network
Configuration, right-click Protocols for <server
instance>, and then select Properties.
-
In the Protocols for <instance name> Properties dialog
box, on the Certificate tab, select the desired certificate from
the drop down for the Certificate box, and then click OK.
-
On the Flags tab, in the ForceEncryption box, select Yes,
and then click OK to close the dialog box.
-
Restart the SQL Server service.
To enable SSL Encryption on the client side:
-
Copy either the original certificate or the exported certificate file to the client
computer.
-
On the client computer, use the Certificates snap-in to install either
the root certificate or the exported certificate file.
-
In the console pane, right-click SQL Server Native Client Configuration,
and then click Properties.
-
On the Flags page, in the Force protocol encryption box,
click Yes.
finally, set your connection string within the application to 'Use
Encryption for Data=True'.
Driver={SQL Native Client};
Server=myServerAddress;Database=myDataBase;Trusted_Connection=yes;Encrypt=yes;
That's really not all that difficult. One more reason to have a more secure infrastructure!>
Boredom is a bad thing! Especially when you are putting off work.
So what do I do to waste my time? Check out local user groups. The websites
at least. A few days ago I posted a few links to some promising groups.
To my disappointment there really aren't that many Microsoft oriented user groups
in Toronto. I wouldn't call it a bad thing. More of an opportunity.
I have determined that TorontoSql.com, TorontoSql.net, and TorontoSql.org
were not registered. So for $30 I registered all three of them. Now I
have to put them to good use. Currently they are pointed to
www.syfuhs.net,
until I find a proper home.
More to come on that front!
Just some links to read. Carefully. There's a
lot of
information. These posts were made by Paul S. Randal on
www.sqlskills.com.
I'll do a more thorough job of weeding out information when I'm not strapped for time.
Since moving to Toronto I have been looking for user groups that I
think I could benefit from. So far I have found a couple of interest:
|
I'm
still looking, but these look promising.
|
|