Directory Programming .NET

If I have 3 domains I want to join via ADFS, here is what I have come up with as far as servers/certs/software needed.

Additional Servers Required

·         6 Windows Server 2003 R2 Enterprise Edition servers

SSL Certifications Required

·         6 SSL certs, one for each federation server (and proxies)

·         3 Token signing certs, one for each federation server

·         3 Client Authentication certs, one for each FS proxy

Software Required

·         Web applications: ASP.NET 2.0 on Windows Server 2003 R2 Standard

·         Outlook Web Access: Exchange 2007 server

·         SharePoint: Microsoft Office SharePoint Server 2007 or Windows SharePoint Services 3.0

The client has to be willing to accept all these costs before implementing ADFS, there will probably need to be some trimming, what are your thoughts Joe?

Well, I'm not Joe :)

But the first question is, what do you mean by "I have 3 domains I want to join using ADFS"? 

If you have 3 domains on the same network, do they have trusts in place already?  If so, ADFS works well using Windows trusts, so you may be able to boil it down to a single instance. 

What are you uptime requirements?  You should only need 3 SSL cert's, because you only want 3 ADFS instances.  You may have more than one server per instance (for high availability or load), but they use the same namespace.  We usually use the same cert for both SSL and token signing, so you only need one cert per farm.  That would take you down to 3 total, assuming you need seperate ADFS instances.

Important note:  OWA doesn't work with ADFS

~Brian

I agree with Brian.  I personally like keeping the token signing cert separate, but you definitely don't have to.  For me it comes down to who I have to share the private key for the cert with and I don't like having to give mine to the load balancer guys who configure SSL termination on the F5 we use.

You definitely don't need physical boxes for all that stuff.  Unless you have a ton of traffic coming, it is pretty hard to overload a box doing only ADFS.  However, depending on how this is being deployed, there might not be an easy way to piggyback them all together on the same physical boxes.

You definitely should not try to run multiple federation servers on the same IIS box.  It can be made to work (I've done it), but the management tools assume there is only one trust policy per box and will tend to cause you grief.

Nate, I thought you had OWA working with ADFS?  I'm curious now about Brian's comment.  I haven't had a chance to try ADFS with OWA yet, so I wasn't sure what the verdict was.  I figured it might work as a token app and definitely not as a claims-aware app.

Brian, thanks for dropping by.  It is nice to have the heavy hitters in our midst from time to time.  :)

I do have OWA working, of course that is in the lab and I haven't done much in OWA, but you login once and OWA is one of the resources you have access to, and when I log out of OWA or from any other app, you're logged out, so unless there is some internal working that break down in OWA I can't speak to that yet.  I have it setup as a token app.

The 9 certs I was talking about (Server SSL, Token signing) make sense to combine those for cost.  What about the 3 client auth. certs, those are different aren't they?  Are they not needed?

Right now I believe the setup will be on same wires so combining will most likely be possible, but they wanted to know that it could be split up to separate physical spaces.

So it sounds like my costs could be:

3 SSL certs: FS, FS-P and token signing reusing the same one each

3 Enterprise licenses, if having virtuals is possible without too much additional cost

3 boxes for those to go on, if not already in place.

What about those client auth certs though?

Thanks,

Nate

The FSP certs must be actual SSL client certificates, so a normal SSL cert may not work for that since it usually doesn't have client authentication EKU, just the server auth one. 

On the other hand, the FSP cert is basically just an internal mechanism that is never surfaced outside of the FS system itself, so the only things that have to trust that cert are the FS and the FSP itself.  As such, they could easily be self-signed or issued out of an internal CA and would have no cost associated.

One thing to consider as a possibility for co-hosting on the same OS image is that you can easily mix other web apps with ADFS if you want to.  Since it is pretty low stress on the box, it doesn't use much in the way of resources.