Brian Puhl's Weblog

Starting Over...

It's time to start over with this whole blogging thing.  But it was important (to me at least) to figure out why this one died such a horrible death when it had so much potential.  And I realized, that it's because of the darn namespace - "blogs.technet.com"...sort of puts a damper on this things when I'm just interested in ranting or raving or talking about my daughters, and that cascaded into me not really being interested in throwing the cool AD/ADFS/Identity stuff up here when I could.

So I've started over, with my own blog:  http://imav8n.wordpress.com

I know that most of the people subscribed here only want the AD stuff.  That's nice.  I'll do my best to categorize my posts, and we'll see how it goes from there.

 ~B

Identity and Access Webcast Series

Here's some info on some upcoming webcasts...  This first series is for the "Technical Decision Makers", but I'll post the "IT Pro" series when they get announced.

-Brian

--------------

Microsoft offers a broad range of technologies and products to enable a customer’s identity and access infrastructure. This web-cast and virtual lab series is designed to educate Technical Decision Makers (TDMs), and IT Professionals about Microsoft’s IDA solution areas centered around the following products:

• Windows Rights Management Services (RMS)
• Active Directory Federation Services (ADFS)
• Microsoft Identity Integration Server MIIS)
• Certificate Lifecycle Manger (CLM)
• Active Directory (AD)

These webcasts are structured under different categories. The categories take attendees from Product/Solutions Overview, what the product is and how it can help the customer’s infrastructure, to Deployment, and through the different categories to, “What is New for the Future”.  

Our kickoff webcast by Peter Houston, and Product/Solution Overview webcasts are for the Technical Decision Makers, while the following webcasts categories will be for IT Professionals.

Join our webcast series to help plan for the future, deploy new solutions, manage and optimize your existing IT infrastructure

As Technical Decisions Makers you should attend (a) our kickoff webcast IDA Vision and Strategy, and (b) Product Overview webcasts segment, to see how our IDA products can be improve cost, increase protection for your IT infrastructure Then encourage your IT Professionals to attend our following webcasts on deeper IT content.

We will be announcing more upcoming webcasts for IT Professionals very soon.

First IDA Webcasts:

(a) IDA Vision Webcast

Title: Microsoft Identity and Access (IDA) Vision and Strategy

Description: Identity and access in connected systems has gone beyond a technical concern and become a top business issue as organizations look to reduce security risk, decrease operational costs, satisfy regulatory requirements, and deepen their electronic relationships with customers and partners. In this session, learn about Microsoft's vision for identity and access technology, including the evolution of Active Directory (AD), Microsoft Identity Integration Server (MIIS), 'CardSpace', and Certificate Lifecycle Manager (CLM). You will also gain insight into Microsoft's vision for IDA in the future.

Presenter: Peter Houston

Date/Time: 11/10/2006, 10:00Am - 11:00PM Pacific Time

Click here to Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032315361&Culture=en-US

(b) Product Overview Webcasts:

Title: Information Protection with Windows Rights Management Services (RMS)

Description: Protecting confidential information and intellectual property, such as e-mail and documents, is critical to the success of many organizations…

Presenter: Tim Upton

Date/Time: 11/16/2006, 1:00 PM – 2:00PM Pacific Time

Click here to Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032313768&Culture=en-US

Title: Introduction to Microsoft Certificate Lifecycle Manager

Description: Join this webcast to learn about the new Microsoft Certificate Lifecycle Manager (CLM)…

Presenter: Amesh Mansukhani

Date/Time: 11/20/2006, 1:00 PM – 2:00PM Pacific Time

Click here to Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032313484&Culture=en-US

Title: Web Single Sign-On and Identity Federation with Active Directory Federation Services

Description: As organizations extend their information technology (IT) infrastructures to provide partners with access to Web-based applications, they face difficult administrative and security challenges…

Presenter: Howard Ting

Date/Time: 11/27/2006, 11:00 AM – 12:00PM Pacific Time

Click here to Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032313783&Culture=en-US

Title: Identity Life-Cycle Management with Microsoft Identity Integration Server 2003

Description: Join this webcast to see how Microsoft Identity Integration Server (MIIS) 2003 enables the automation of identity life-cycle management in the enterprise…

Presenter: Lori Craw

Date/Time: 11/29/2006, 11:00 AM – 12:00PM Pacific Time

Click here to Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032313486&Culture=en-US

Regards,

ADFS Documentation

Wouldn't it be cool if there was a blog where someone was posting documentation about ADFS?

Well looky here - apparently this has been around for a while, but since I just recently discovered it I thought I'd share...

http://blogs.technet.com/adfs_documentation/

Who's on... huh?

If Bud Abbott and Lou Costello were alive today, their infamous sketch, "Who's on First?" might have turned out something like this:

COSTELLO CALLS TO BUY A COMPUTER FROM ABBOTT

ABBOTT: Super Duper computer store. Can I help you?
COSTELLO: Thanks. I'm setting up an office in my den, and I'm thinking about buying a computer.
ABBOTT: Mac?
COSTELLO: No, the name's Lou.
ABBOTT: Your computer?
COSTELLO: I don't own a computer. I want to buy one.
ABBOTT: Mac?
COSTELLO: I told you, my name's Lou.
ABBOTT: What about Windows?
COSTELLO: Why? Will it get stuffy in here?
ABBOTT: Do you want a computer with Windows?
COSTELLO: I don't know. What will I see when I look in the windows?
ABBOTT: Wallpaper.
COSTELLO: Never mind the windows. I need a computer and software.
ABBOTT: Software for Windows?
COSTELLO: No. On the computer! I need something I can use to write proposals and track expenses and run my business. What do you have?
ABBOTT: Office.
COSTELLO: Yeah, for my office. Can you recommend anything?
ABBOTT: I just did.
COSTELLO: You just did what?
ABBOTT: Recommend something.
COSTELLO: You recommended something?
ABBOTT: Yes.
COSTELLO: For my office?
ABBOTT: Yes.
COSTELLO: OK, what did you recommend for my office?
ABBOTT: Office.
COSTELLO: Yes, for my office!
ABBOTT: I recommend Office with Windows.
COSTELLO: I already have an office with windows! OK, let's just say I'm sitting at my computer and I want to type a proposal. What do I need?
ABBOTT: Word.
COSTELLO: What word?
ABBOTT: Word in Office.
COSTELLO: The only word in office is office.
ABBOTT: The Word in Office for Windows.
COSTELLO: Which word in office for windows?
ABBOTT: The Word you get when you click the blue "W".
COSTELLO: I'm going to click your blue "w" if you don't start with some straight answers. What about financial bookkeeping? You have anything I can track my money with? ABBOTT: Money.
COSTELLO: That's right. What do you have?
ABBOTT: Money.
COSTELLO: I need money to track my money?
ABBOTT: It comes bundled with your computer.
COSTELLO: What's bundled with my computer?
ABBOTT: Money.
COSTELLO: Money comes with my computer?
ABBOTT: Yes. No extra charge.
COSTELLO: I get a bundle of money with my computer? How much?
ABBOTT: One copy.
COSTELLO: Isn't it illegal to copy money?
ABBOTT: Microsoft gave us a license to copy Money.
COSTELLO: They can give you a license to copy money?
ABBOTT: Why not? THEY OWN IT!

(A few days later)

ABBOTT: Super Duper computer store. Can I help you?
COSTELLO: How do I turn my computer off?
ABBOTT: Click on "START."

First Post with Live Writer

Don't expect a whole lot here - I just installed Live Writer and wanted to see what it was going to be like.

Feels vaguely similar to Onenote, which is good, since I like Onenote - I think I'll keep it... maybe it will help me blog more often.

This post will self destruct in 5

...

4

...

3

...

2

...

1

...

pfft

ADFS and Liability Continued...

hmm...let's see...I wrote a blog, Pam left a comment, I replied to her comment with another blog, and so (if you haven't seen it yet) Pam posted her own blog entry here...  This is actually kind of fun!

You should read (all of) her posts anyways, but to save some screen flipping here's the meat of it:

...When I read this, I felt like jumping up and down like the goody-two-shoes in the second row, me me me me oh I know the answer pick me!!!

If they were to use an Information Card for the active confirmation prior to a user making changes, users wouldn’t need to remember a password at all. You would get the impediment of requiring credentials, without the support burden attached to maintenance of a rarely-used password. Alternatively, if you felt the need to have a password, you could require a managed information card. In that case, the user would be authenticating to the home IdP instead of to the outside application, taking the password management burden off of your partner and consolidating password use to a single centralized source that would theoretically be much more commonly used, and therefore less likely to require frequent recovery. Not to mention that the Enterprise could audit use of the managed infocard in this context.

This seems to me to be a perfect scenario to envision a hybrid passive/active federation combination instead of passive federation for 85% of user activity, and partner-managed password authentication for the remaining 15%. Yes? If so, it just goes to show that the scenarios are out there, and for more than just the eBusiness world.

Brian, what do you think?

So...let's see...What do I think? 

I don't think the problem is in the way that the credentials are stored.  Let's suppose it's an InfoCard from some Identity Provider, then the liability would then fall on that Identity Provider if/when a users account gets compromised.  Why would someone sign up for that?  In the case that we're dealing with internally, Microsoft is the Identity Provider, and our lawyers don't want to sign up for the risk - why would anyone else?

Thinking about this slightly differently – Our lawyers have the problem, because if someone hijacks my corporate user account, and goes into my 401k and wipes out my retirement savings – who is ultimately responsible?  If Microsoft did the authentication, Microsoft is, if the partner did it, they are, and if some 3rd party identity provider did the authentication – then THEY are responsible (would we even consider a 3rd party - umm...let's hope not)

So let’s say we use an infocard.  And not only that, but we use a Managed infocard.  Ok, so now I’ve got a managed card on my machine – So when someone hacks my account, selects the highlighted infocard, and THEN wipes out my 401k… Now who’s responsible?

I can absolutely see where an InfoCard can help the end user - but I'm the IT Geek who's trying to deploy the infrastructure.  How do I sell being an Identity Provider to my CIO?

Comment on ADFS Liability

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

Cheers,

Pam

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.

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

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

QUESTION:

<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,
M

x64 Domain Controllers

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.

REMEMBER - "IT DEPENDS" and "YOUR MILEAGE WILL VARY"

________________________________________
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.

Useful repadmin switch

Repadmin is the "swiss army knife" of AD tools - But the following can be one of those "big red buttons" that you keep in your back pocket and hopefully never need.  But sometimes it's just useful to slow things down until you figure out what's going on...

repadmin /options * +disable_outbound_repl

repadmin.exe - the tool
/options - Did you even know this was there?  If not, try repadmin.exe /experthelp
* - means run against all DC's
+disable_outbound_repl - Self explanatory?  I hope so...

Please don't go running commands willy-nilly in your production environment - play with repadmin.exe (or any other tool) in a lab or against some virtual DC's so you can learn what it's doing and how to use it...then sit back and let the tools do all the work for you.

AD Training

hmmm....ok, so here's an interesting problem:  I'm  a Microsoft employee.  My blog is hosted on Technet.com.  And I'm pretty sure that there is a policy somewhere, which I'm unaware of, that addresses blog posts about 3rd party companies...  But I've never really been one for following too many rules anyways, so here you go:

I wrote a post back in May about changes to our organizational structure for supporting AD internally at Microsoft.  While I still think the re-org was a great thing to happen within IT, and we're making big progress on many things that had been stalled in the past (ADFS, smartcards, selective auth forest, etc...) - one thing that I noticed were all of the new faces who were going to be managing the DC's.  Now, most people in the org have AD experience, but let's face it, there's a big difference between reviewing schema extensions and doing delegations; versus troubleshooting replication or a server on which lsass.exe is taking 90% of the CPU.  Both can be difficult, but they are seperate skills.  So, to make a long story short, (too late), I fired off an e-mail to Dean at MSETechnology to see if he could help us out with some training.  Many people who have been around AD for a while know Dean (or at least "of" him), whether it's the random references in Joe's blog, his answers on ActiveDir.org, or from NetPro's Directory Experts Conference. 

Anyways, after a bit of back-and-forth figuring out the logistical details, Dean came on-site here in Redmond and has spent the last week giving what can only be described as the most entertaining, in-depth training on AD that I've ever seen.  Topics ranging from replication and topology, to sid history/filtering, to the most...ummm...."descriptive"...segment on the FILE replication service which I've ever sat through, I would have to say that if you're looking for some 300-400 level AD information (as opposed to someone standing up reading a book to you), then this was the class you want to be in. 

There's no comparison to the quality of the content, but two things stood out most...and note, that I didn't even sit through the entire week, but was coming and going at random:

1. While there was definitely structure and order to the content, there was never hesitation to go off on wild tangents which would ultimately enhance the topic being discussed.  Most impressive are the impromptu labs, which went something like:  "That's a great question...why don't we log into the VPC and try running xyz command and see what happens...ok, well since that didn't work, let's figure out why and then see what we should do."  Having taught classes before, I can say that it takes an ENORMOUS amount of confidence in your knowledge to make up labs on the fly.
   
2. Professionalism - Yes, a couple of you just looked and said "what?  that's not the Dean I know!"  Well, actually it is and you know it, but it's fun to play.  Most mornings and some afternoons we sat down to go over the class progress and to make sure we were hitting the right topics.  There wasn't ever any hesitation to change things "on the fly" (again, very difficult for 'structured' instructors) and the open dialog was exactly what we needed to make sure that everyone was getting the most out of the class.  He truly cared about making sure we got the most of the time spent.

So if you're looking to bring in some custom (in-depth, not MOC based) training, and wondering what other people have done, then MSE Technology is worth a look. 

AD and DC Builds, tweaks, configurations... The Registry

The first installment, what our hardware looks like, may have been useful...but I know that's not really the juicy gossip that everyone is looking for...so here's a quick and follow-up with the registry tweaks that we set internally...

Strict Replication is enabled on Windows Server 2003 - For Windows 2000 there is the "Correct Missing Objects" key which has similar (though reversed) funcationality.  Basically, this stops a DC from replicating lingering objects
HKLM\system\currentcontrolset\services\NTDS\parameters" /v "strict replication consistency" /t REG_DWORD /d  0x1

The Exchange team requires this for RPC/HTTPS functionality
HKLM\system\currentcontrolset\services\NTDS\parameters" /v "NSPI interface protocol sequences" /t  REG_MULTI_SZ /d "ncacn_http:6004"

Causes an event to be logged after each online defrag task.  The event includes file statistics about the DIT including whitespace.  We run a seperate task to harvest these events for database file maintenance.
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "6 Garbage Collection" /t REG_DWORD /d 1

Set to 5 causes an event to be logged for "expensive" and "inefficient" queries.  Extremely useful during troubleshooting isolated load issues.
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "15 Field Engineering" /t REG_DWORD /d 5

The following keys enable the database perfmon counters (note that these are just the reg keys, you have to enable the counters themselves as well using "Lodctr.exe Esentprf.ini")
 HKLM\system\currentcontrolset\Services\ESENT\Performance /v "Open" /t REG_SZ /d "OpenPerformanceData"
HKLM\system\currentcontrolset\Services\ESENT\Performance /v "Collect" /t REG_SZ /d   "CollectPerformanceData"
HKLM\system\currentcontrolset\Services\ESENT\Performance /v "Close" /t REG_SZ /d "ClosePerformanceData"
HKLM\system\currentcontrolset\Services\ESENT\Performance /v "Library" /t REG_SZ /d  "%systemroot%\system32\esentprf.dll"
HKLM\system\currentcontrolset\Services\ESENT\Performance /v "Squeaky Lobster" /t REG_DWORD /d 1

Just what it sounds like.  Causes DFS to use site costed referrals.
HKLM\System\Currentcontrolset\Services\DFS\Parameters" /v "SiteCostedReferrals" /t REG_DWORD /d 1

Last but not least, on some of the servers we set LdapSrvPriority and LdapSrvWeight.  These are used for load balancing and isolation, but are not consistent across all of our servers.  Older/slower hardware gets lower weight, and special case servers that we want to shield from general traffic get higher priorities.  Check here for more info on these keys:  http://support.microsoft.com/?id=306602

AD and DC Builds, tweaks, configurations... (1)

I received a mail from a blog reader (Jim) who asked:

"Can you provide any insight regarding and tweaks or configuration settings you guys use on your DC builds?"

Sure, I'm happy to do this, so here I am typing happily along, and realized that there is a lot more configuration/tweaking/settings that we use than I should reasonably put into a single blog entry.  Instead this will be the first of multiple entries...

So, let's start at  the very beginning (it's a very good place to start)...  With our standard hardware platforms.  All MS IT domain controllers are based on either our "large" or "small" SKU...internally, we call these are DC-E (enterprise) or DC-F (field) platforms.

The DC-E specs are:

• DL585
• 2 x 1.8GHz AMD Opteron (64-bit) dual core processors
• 16GB RAM
• 172GB total storage
• Internal Array Controller - 2 x 72GB - RAID 1
• 50GB OS partition
• 18.8GB partition for Log files (L: Drive)
• Array Controller 1 - External Storage - 6 x 36GB - RAID 0+1
• 103.2GB partition for DIT, SYSVOL, Backups (M: Drive)

The DC-F specs are:

• DL385
• 1 x 2.2GHz AMD Opteron (64-bit) dual core processor
• 8GB RAM
• 137GB total storage
• Internal Array Controller
• Disk 0 - RAID 1 - 2 x 72GB
• 50GB OS partition
• 18.8GB partition for Log files (L: Drive)
• Disk 1 - RAID 0 + 1 - 4 x 36GB
• 68.8GB partition for DIT, SYSVOL, Backups (M: Drive)

All of our DC's run x64 OS's...well...unless we have some dogfood requirement for 32-bit OS runtime (which we periodically do)...but for all intents and purposes, let's just pretend because we really WANT to run all 64-bit OS's.

Somewhere previously I mentioned that our average DIT size is 10-11GB on disk.  The DC-E with 16GB of RAM let's us cache the entire database with room for growth, the DC-F with only 8GB of RAM is usually deployed where we need services, but don't have the load so caching is less of an issue.  In that case, the DC-F is significantly cheaper for us.

Interesting SSID and Reusing Attributes

I bought a new truck a few months ago, and right on schedule (as the salesman promised), as I was coming due for my first oil change, I got a card for my first one free at the dealership.  Never being one to turn down a free deal, I dropped in the other day, handed over my keys, and directed to the lobby where the offered, "Free cofee, pastries, and wireless internet."  This is Redmond after all.

So sitting down with my laptop, coffee cup, and a donut, I fired up my laptop to synch my e-mail.  Viewing the available wireless networks, I almost laughed out loud when I read the SSID:

LJ Chev Cust Net - Ask Cashier for Key

99% of you probably just looked at that and went, "Umm, yeah...DUH!"  But both of the people in the office that I mentioned this to said, "Whoa, neat..." which by my statistical methodology made this blog-worthy.

So what does this have to do with AD?  It reminds me of a common question that goes through the AD discussion alias at work.  The details change, but the gist of it is always something akin to:

"I've got a customer/application/user that is asking whether there are any applications (MS or 3rd party) that use the drink attribute, they are creating a custom password reset portal, and need someplace to store the answer to the secret-question."

Three people just fell out of their chairs laughing, two of you did one of those "I can't believe it" head smacks, and there's one guy who just made a note to himself that he needs to update his portal application to use a different attribute.  THAT'S the guy that I want to talk to.

Reusing attributes is bad, each and every one has an intended purpose...well...ok, there are those pesky extensionAttributes, but let's not get picky...  If you're creating an application that needs to store data in AD, then go ahead and get an OID branch, and create one... there's a ton of documentation out there on how to do this.

Someone is going to say something about being so cavalier with the schema.  Yes, I understand that it's a one-way operation, and I always advocate doing appropriate testing before mucking with your production schema, but I've always been mildly disappointed at the level of FUD that Microsoft created surrounding schema extensions.  Caution and due diligence should be taken with everything you do in Active Directory.

ADFS Certificate Maintenance - v1

Over the past several weeks, we've celebrated the 1 year anniversary of our ADFS deployment.  I say it this way, because the only reason I know this, is that the certificates on the servers keep expiring, and things would break unexpectedly.  Yeah, yeah, yeah...I could have, would have, and SHOULD have been a bit more proactive about this, but our use of ADFS internally is somewhat limited until this summer (aka - fiscal year and budgets) when we're going to start onboarding a lot of new ADFS based services for our users.

So, I wanted to get an idea of where I needed to update the certs.  Since we use a common cert for both the ADFS trust policy signing certificate, as well as the IIS SSL cert, I needed to make sure I replaced them both.  We also use an FS Proxy on the internet, against SSL and policy signing cert required here.  This all made sense to me, so off I go:

1. Change the SSL cert in the IIS console of the FS
2. Change the SSL cert in the IIS console of the FS-P
3. Change the token signing cert on the FS using the ADFS MMC
4. Change the token signing cert on the FS-P using the ADFS MMC

(note:  pet peeve of mine, which I'll probably rant about again... but we can't remotely administer the ADFS servers using the MMC.  You have to TS onto the box, or write your own scripts to do things remotely....  grrrrrr... yes, the product group knows, yes I remind them every chance I get...unfortunately no, it didn't make it into R2.)

Ok, so at this point, I'm thinking to myself, "cool, this annual maintenance is done."  Probably took 7 full minutes before my phone rang that EVERYTHING was broken.  Seems that I forgot that a year ago when we set this up, I had to send a copy of the token signing cert to the federation partners.  Their FS-R's need to be able to validate the cert.  Ok, drop that in e-mail, follow-up with a phone call...everything's working from internal now (ie. users connecting directly to the FS server).  RDP'd back to my home computer, so I could get a view of this thing from the internet though and it's still failing.

Perusing the event logs on the FS-P (which look like a Christmas tree...if Christmas colors were red and yellow) I find:

The Federation Service Proxy encountered an exception when it called a Federation Service Web method.
Federation Server URL: https://corp.sts.microsoft.com/adfs/fs/FederationServerService.asmx
Web method: GetProxyTrustConfiguration
Proxy certificate thumbprint:
<snipped by brian>

This may cause a user request to fail.

User Action
The exception details may give an indication of the precise problem.

Check network connectivity between the Federation Service Proxy and the Federation Service.

Ensure that the Federation Service is running.

Ensure that the Federation Service Proxy client authentication certificate has been added to the list of proxy authentication certificates in the Federation Service trust policy.

Ensure that the Federation Service Proxy client authentication certificate chains to a root that is trusted by the Federation Service.

Ensure that the Federation Service Internet Information Services (IIS) Secure Sockets Layer (SSL) server certificate chains to a root that is trusted by the Federation Service Proxy.

Ensure that the Federation Service Uniform Resource Locator (URL) that is configured in the Federation Service Proxy web.config uses the name that is the subject of the Federation Service IIS SSL server certificate.

Additional Data
Exception details:
System.Web.Services.Protocols.SoapException: System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
   at System.Web.Security.SingleSignOn.FederationServerService.MethodInvocationCheck(MethodAuthenticationLevel DesiredAuthentication)
   at System.Web.Security.SingleSignOn.FederationServerService.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)
   --- End of inner exception stack trace ---
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)
   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I've bolded the important part above.  When I zipped right back to the FS server where I found the following event:

Description:
The Federation Service failed a privileged Web method call because the caller's client authentication certificate is not configured as a Federation Service Proxy certificate.
Certificate thumbprint: <snipped by Brian> 

User Action
Ensure that the trust policy is properly configured with all valid Federation Service Proxy certificates.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Back to the ADFS snap-in, and in the trust policy there is an FSP Certificates tab.  Added the token signing cert here as well so everything matched, and voila! auth started working again.

There were a couple of reasons I wanted to jot this down:

1. As the ADFS service scales, managing the certificates is going to become significantly more important and require a lot of advanced planning.  While I'm a HUGE fan of documenting and testing operational processes, etc... The fact that this will require coordination between the FS-A and the FS-R provider, and that this once-a-year function requires so many touch points, is just scary.
2. I wanted to point out the quality of the events that are being logged by the service.  The ADFS team put a lot of thought into getting the "right" information into the logs, so an administrator can quickly figure out what's going on with the service.  There is still granular debug logging available, but you shouldn't really need to use it that often.  IMHO, too many admins are jaded against the event logs anyways (rightfully so?), but I still believe that if eventvwr isn't your first stop, then you're probably not doing your job right.  For federation services, this is definitely the case.  ADFS Product Team - THANK YOU.