BPuhl’s Blog

A little bit of everything without actually being much of anything

Archive for September, 2006

Comment on ADFS Liability

Posted by BPuhl on September 21, 2006

My favorite Calgary-ian Pam left the following comment on my last blog post:

Hm.  In a perfect world, there would need to be a contractual component to any and all technical federations, and those contractual components should go through review by the privacy officer, and also by the admin team.  
Companies and admin groups need to get religion over the process involved with creation of federations, if for no other reason than to protect themselves from liability.  
Here is more about liability and federation:  http://www.rsasecurity.com/go/siliconcom/liability.asp

I am SOOOO glad she did too, because liability is one of the hardest problems to deal with when deploying ADFS, and something that I’ve personally been harping about to our internal deployment team as we develop our onboarding process for new federations.  In fact, one of the topics that I’ve been presenting at various TechEd’s and the upcoming ITForum lately, is “How Microsoft IT Deployed Active Directory Federation Services”.  In that talk, I’ve dedicated an entire slide, to just some of the impacts that liability can have, whether your providing the user authentication or the resources.  In fact, one of the comments that I make during my talk, is:

I’ve been involved with Microsoft’s Active Directory for 5 years, and never had any reason.  But I was tasked with deploying AD Federation Services, and within a week of the project starting up, I had met with some attorneys in our Legal and Corporate Affairs group.

A great example of technology vs. liability is the ongoing discussion that we’re having with one of our business partners, about providing federated access to their internet portal.  This partner though, happens to be one of the providers of financial services to Microsoft employee’s.  From the partners perspective, the idea of federation is wonderful…they see it increasing their security, reducing their risk (since they still allow SSN’s as user names), and reducing the amount of overhead they have for constantly resetting users passwords.  In fact, one of their architects commented that there were nearly as many users who require a password reset EVERY TIME a user attempted a login, as there were who didn’t.

Enter the Microsoft attorneys…

They looked at the technology, and got a pretty quick understanding of the risks, limitations, and potential uses for ADFS.  They just as quickly built the following scenario

So Joe User’s password gets compromised.  Not only can someone use it to gain access to some set of corporate resources, but now they can also go in and mess around with his retirement portfolio?  And they would do this, because during the logon attempt, “Microsoft” verified that the user was actually Joe?  Ummmm….No.

This is basically the story of how Microsoft has ended up asking some of their higher impact business partners, to create a 2-tiered authentication model.  In this case, a user can log in using ADFS authentication to view their information…but as soon as they want to make a change to their information, they’ll need to enter their application specific credentials.

According to the partner, approximately 85% of all logons are just to view the data anyways, so it’s still a win…but it also virtually guarantee’s that when a user does want to make a trade, they’ll need to reset the password because now they DEFINITELY are not going to remember what it is.

So what does all this mean – it means that I agree 100% with Pam’s comment, that IT people are going to have to get religion over the process of creating federations, and the impact that it has to their business.


Posted in ADFS, Digital Identity, Identity and Access | Leave a Comment »

ADFS and Domain Admins (or anyone else for that matter)

Posted by BPuhl on September 18, 2006

I spend a lot of time answering questions or making comments in e-mails that would make good blog posts.  So it may seem a bit cheesy (at least it does to me), but it’s turning out that reposting these e-mails seems like an easy way to do this…so here’s another one…hope you don’t mind (again, some edits to protect the innocent)…(and fix typo’s)…

From: Brian Puhl
Sent: Monday, September 18, 2006 1:18 AM
To: ADFS Discussion
Subject: RE: Domain Admin and ADFS

More generically – it’s a good thing to remember that anyone who can join an machine to a domain, can install ADFS and create federations.

We had several conversations with the ADFS team during R2 dogfooding about this – to summarize weeks of discussions into a couple of bullet points:

  • Generally speaking, “IT” controls the network perimeter – So the ‘threat’ of setting up an incoming federation to allow 3rd party access to your network would require someone who was deploying ADFS to also be able to deploy applications to the internet
  • Anyone could configure ADFS, and work with a partner to configure an outbound federation, enabling all users in the directory (and trust realm) to ADFS authenticate to an application.  The primary concern here was data disclosure, but the only data they could disclose are things that are already readable by the user in the directory anyways, so there were a lot easier ways to disclose this info if that was the goal.

From the MS IT perspective, our largest concern was actually the support impact.  For example, you go to a website one day, and it just suddenly “logs you in”, because someone internally joined an R2 machine to the domain, and worked with the application owner to set up the federation.  This is all goodness, until the day that the federation breaks – Because the users will call the help desk (approx $50 per call), and it is extremely difficult to track down where the federation server is, who owns it, how it’s configured, why it broke, etc…  All of this takes administrator time and effort ($$$), for what is essentially a user impacting rogue application.

The ADFS Product Group has a DCR <Design Change Request> to give us more control over rogue ADFS instances in LH Server.  I don’t know the status, but they understand the problem of needing to answer the question “Who do we have federations with.”

Brian Puhl
Microsoft IT


From: T
Sent: Monday, September 18, 2006 12:36 AM
To: ADFS Discussion
Subject: RE: Domain Admin and ADFS

No, as domain admins can do whatever they want to in their domain

From: M
Sent: 15 września 2006 19:32
To: ADFS Discussion
Subject: Domain Admin and ADFS


<My customer with multiple domains> are going to upgrade their servers to R2 and they want to know if there is any way to prevent Domain Admins of installing and configuring ADFS

Any comment/suggestion will be greatly appreciated

Best regards,

Posted in ADFS, Digital Identity, Identity and Access | Leave a Comment »

x64 Domain Controllers

Posted by BPuhl on September 13, 2006

Had an e-mail thread with Joe recently, which also resulted in this blog entry.  He’s a consultant for another big tech company, and was working with a customer that was migrating a lot of non-domain joined machines to AD as well as deploying other AD aware applications.  The net result though, is that he was in the unenviable position of having no performance baseline to go off of, and a bunch of customers asking how many 64-bit domain controllers they needed to buy.  And therein lies the problem, there just aren’t that many 64-bit DC’s deployed out there (yet), so if you’re starting from scratch, where do you start?

Well, to make a long story short (too late), a few e-mail back and forth later and I fired off some of the stats that we use internally here at Microsoft.  In the spirit of copy/paste, here’s the mail I sent (slightly edited to protect the innocent), if you don’t have anything else to go on or just want some general reference…then you can use this.


From: Brian Puhl [mailto:Brian.Puhl@microsoft.com]
Sent: Wednesday, September 06, 2006 6:11 PM
To: Joe
Subject: RE: Ping…

Well, like you said, “it depends” and “your mileage WILL vary.” 

It’s tough, because we don’t plan based on numbers of users, workstations, or anything like that…  We base capacity on performance trends, which I realize is ultimately where you’re trying to get <customer> to…  So instead, here are some details from our Redmond domain.  These are live numbers, which you can use to approximate.  Remember that MS is probably a higher utilization environment than <customer>, so you can use these to build a deployment plan with the expectation that you could end up slightly over capacity. 

Domain Details:
   99%+ of the users are in a single AD site, so assume that this is all for a single site.
   49K user accounts (includes service accounts, etc…)
   160K computer accounts
   17 DC’s for authentication load, app’s – everything but exchange
   5 DC’s in a separate dedicated Exchange site, shielded from auth load

Typical auth DC spec
   HP DL585
   4 x 2.2GHz AMD64
   16GB RAM (12 GB dit file)
   2 or 4 spindles (0+1) for OS and logs
   6 spindles (0+1) for dit, backup, and sysvol
Typical load profile (randomly picked a DC and pulled open perfmon while I’m typing this mail) – see note below
   Ave CPU – 55%
   Ave Disk Queue – 0.1

   Server Sessions – 585
   NTLM Auths – 215
   Kerb Auths – 92
   DS Client Binds/Sec – 44

   Gigabit NIC card
   NIC Output Queue – 0

Major thing to note about the perf data – We’ve got 3 DC’s offline at the moment due to dogfooding, so this perf load would be with 14 DC’s online.  Our target utilization is 20-40% sustained peak CPU.

Also, based on our experience, we’re rarely NIC bound.  When we see overloaded DC’s, they typically tend to be disk bound or processor bound.  Even when we had x86 with 4GB of RAM, the memory pressure just translated into disk queues, so when you’re spec’ing out your servers I would be least concerned about the connectivity.  You probably also noticed in the whitepaper that x64 doesn’t give you a whole lot of benefit in a pure auth environment.  These operations tend to be disk bound even in a 64-bit OS.

I think you’re hoping for a “5000-10000 user” type answer, but even if I gave you a completely wild guess, It would probably do more harm than good in your conversations with the customer.

Does this give you a better idea?  Are there other details that would help you make a better guess? 

The whitepaper that I referred to is the Active Directory 64-bit Performance Comparison paper, located here.

Posted in Active Directory, Random Tecnical Stuff | Leave a Comment »