Welcome to SharePoint Saturday—The Conference Real World Claims in ADFS and SharePoint 2010 (Sat-S2C-104) Architect – Level 500 Thomas “Doc” Carpe Liquid Mercury Solutions (Colossus Consulting) www.liquidmercurysolutions.com

Welcome to SharePoint Saturday—The Conference Thank you for being a part of the first SharePoint Saturday conference Please turn off all electronic devices or set them to vibrate. If you must take a phone call, please do so in the hall so as not to disturb others. Open wireless access is available at SSID: SPSTC2011 Feel free to “tweet and blog” during the session Thanks to our Diamond and Platinum Sponsors:

Introduction About Me My Company 15 years with MS products: Commerce Server, Site Server, Office Web Services, CMS, BizTalk, and SharePoint 2001-2010 MCPD SharePoint 2010, MCTS MOSS 2007 @thomascarpe on Twitter My Company Est. 2005, Baltimore, MD MS Gold Partner (since 2010) SharePoint specialists, dev focus 10 staff, 6 technical, growing

What do I mean by “Real World Claims”? Claims Based Authentication I’m not talking about just a development box Practical application, not just theory Refers to promises made, not just the technical definition

Goals Deepen your awareness and understanding What’s possible? What to beware? Whatever it may seem, I don’t want to scare you away from ADFS or Claims Based Auth. Despite obstacles, there is much to be gained What are the opportunities? Let’s Share and Have Some Fun!

What I’m Not Covering Ground well covered elsewhere What’s Claims, what’s it for? How to configure ADFS and SharePoint I have 120+ pages of walkthroughs and docs(!) If you want details, buy my book read my blog Pure AD to AD federation Things too complicated for just an hour We’re not gonna develop code “live” here today Configuring ADFS for Office 365 or Azure ADFS farm configuration

SP+ADFS: Major Pain Points Setup is complex and prone to human error Even a simple ADFS / SharePoint setup is 60+ manual steps Many assumptions that underlying infrastructure is correct Client requirements drive every install to be unique Tools are not very well developed Some community tools, all very new Code solutions and PowerShell exist errors, caveats, limits best code would combine good from several sources

SP+ADFS: Major Pain Points Many configuration patterns are still unproven So far, [mostly] only adopted by very large organizations Has yet to catch on in mainstream Less variety + less testing = less support Troubleshooting is difficult One symptom can have myriad causes Error messages aren't very informative Even when you get it working, you’re not done Functional shortcomings Business challenges

Common PROBLEMS & APPROACHES Real World Claims in ADFS and SharePoint 2010 Common PROBLEMS & APPROACHES

The Essential Checklist Checked that SharePoint is SP1 with June CU Refresh? Previous versions of SharePoint had various issues. Certificates in ADFS incorrect/unsupported settings? Just because it let you add them in ADFS does not make them valid. Restart ADFS service and check the event log for event 133. All your certificates in good order – not expired? If you don't have good PKI, ADFS and claims aren't going to work.

The Essential Checklist Does ADFS service account have access to private keys? Restart ADFS service and check the event log. This one also causes event 133. Check the ACLs using certificate manager. Accounted for all AAMs - even in extended web apps? Each one represents a possible Relying Party – or at least a realm identifier – that’s needed. Does every Provider Realm identifier and URL – including the default realm identifier – have a corresponding RP in ADFS with matching realm identifier and endpoint URL? This is fertile ground for typos or just plain missing entries. Map them out and be certain.

Famous Last Words… “Klaatu Barada Nnn.. Necktie, Neckturn, Nickel. It's an "N" word, it's definitely an "N" word! Klaatu... Barada... N*cough*rrmmffnnmm” "Well maybe I didn't say every single tiny little syllable, but yeah, I said them. Basically.“ -Bruce Campbell as Ash

Trouble on the Road Ahead? When the user logs in, does the DNS name for SharePoint match the DNS name of the RP endpoint URL exactly? Some (though not all) configurations where the RP returns the user to a different URL than they left from can result in cookie looping or other problems. Do your ADFS and SharePoint live in different DNS domains? Done properly this shouldn’t be a problem, but complex configurations like this often lead to issues.

Trouble on the Road Ahead? Is Kerberos working on the ADFS web site? Chances are if Kerberos isn’t working, ADFS will likely give you issues – if not now then eventually. Load balancer in front of SharePoint or ADFS? A load balanced configuration increases the chances that the user will return to a different SharePoint machine than they left, or that when one machine goes down they’ll be redirected to another one. Improper load balancer configuration can cause intermittent authentication problems, and absolutely makes troubleshooting anything an order of magnitude more difficult.

Specific Configuration Issues / Solutions For “TrustedMissingIdentityClaimSource”: Does the RP pass through all 3 required claims? If you have an IdP besides AD, is ADFS configured to pass the 3 claims *out* of it as well? Is the Trusted ID Provider in SharePoint configured to accept them by the same names? For “The root of the certificate chain is not a trusted root authority”: Did you add the whole chain of authority as Trusted Root Authority in SharePoint? Can you confirm that the cert used by the SharePoint’s Trusted Identity Provider is one of the ones you added to Trusted Root Authority collection?

Specific Configuration Issues / Solutions For error ID4014: Does the RP’s encryption setting match the settings in the SharePoint web application’s configuration file? For error ID1024 & ID1039: Did you give the SharePoint application pool rights to *SharePoint’s* token encryption certificate private key? If you’re sure you did, you may need to give IIS_IUSRS rights to “C:\Users\All Users\Microsoft\Crypto\RSA\MachineKeys” folder - or hack ACLs for certificates.

Custom WIF Provider Code Problems Wrong .NET Framework version (WIF should usually be 4.0) CryptographicException incorrect “Load User Profile” application pool setting (should be true) insufficient file system ACLs; use auditing or filemon Failure to provide all required claims Optional claim that’s actually required by SharePoint E-mail where the provider does not give you an e-mail Roles when the user is not in any groups; set a default Calling a claim by the wrong schema URL Malformed or incorrect response URL HTTP 503: Failed to translate/map the Issuer URI HTTP 405: Missing a solidus (/) at the end

Gotcha #1 Incompatible Certificate Requests Limited configuration choices Only use “MS DH SChannel” and “MS RSA SChannel” crypto providers SHA-1 and SHA-256 hashes supported – not SHA-384 or SHA-512 Private keys must be exportable On Windows Certificate Authority Best to use only Windows 2003 Server compatible templates Specific Windows Server 2008 templates *may* work, too much chance they won’t Best Practice: Test certs ASAP by restarting ADFS service Any issues will produce event 133 right away Rush ahead without testing at your own risk!

Gotcha #2 The Dreaded Cookie Looping Issue = Can't Log In Lots of causes, few are easy to rule out Things you *can* check SharePoint is old - SP1 + June CU Refresh The AAM URL that matches your RP realm identifier is not your Public URL for that zone RP realm identifiers missing or wrong in either SP or ADFS Ensure TokenLifetime in ADFS >= LogonTokenCacheExpirationWindow in SharePoint STS There’s an underscore in the SharePoint URL O Rly? Yea Rly.

Gotcha #2 The Dreaded Cookie Looping Issue (cont.) Things that are more difficult to prove SSO and cookie handler settings: should domain attribute be added to ADFS or SP? Improperly configured NLB on multi-server ADFS and/or SharePoint DNS or IP address shifts happening behind the scenes Are we returning to a different SharePoint server than the one that sent us to ADFS? Spooky behaviors When user add/drops VPN, NIC-to-Wifi, or switches from internal to public IPs - even on single server configurations When ADFS and SharePoint live in different DNS domains And more...

Gotcha #3 Performance Anxiety “Your SharePoint’s not slow! It’s taking a much needed repose.”

Gotcha #3 Performance Anxiety ADFS and SharePoint are both IIS applications that can fall asleep for various reasons To keep everything awake you have to hit every ADFS server and every SharePoint WFE Some solutions don’t yet support claim based web sites Delays caused by Certificate Authority Long chain of authority Certificate Revocation Lists Unusual or new configuration CA Web Services Load balanced CA farms Multiple firewalls

Gotcha #3 Performance Anxiety (cont.) 3rd party claim provider delays In-House Custom Queries AD might be fast, but what about that custom PeopleSoft Query to Oracle that your junior programmer wrote? If you're hitting a service on your network, performance may vary widely depending on server loads and overall network traffic Is it “The Cloud” – or just “The Fog”? There's lots of “stuff” between you and the cloud. (Air? Angry Birds?) When using a service over the Internet, don’t expect it to be consistently fast. There may be obstacles between your users and the claim provider that don't exist between you and the claim provider.

Real World Claims in ADFS and SharePoint 2010 EVEN IF YOU WIN, YOU LOSE!

Shortcomings that Annoy Users Can't log out Can’t switch users It makes adding new users a pain Double realm selector = annoying Some SharePoint features aren’t claims compatible WebDAV (Explorer View) A variety of third party products Others?

Shortcomings that Annoy Admins & Security Folks Headaches migrating existing users Some tools aren’t claims compatible Certain PowerShell commands Third-party management products Reliance on cookies Replay based attacks force using SSL Shoulder surfing attacks – did I mention you can’t log out? Session based cookies just suck They break the Office client Thanks to ADFS cookies, they do no good anyway

Shortcomings that Annoy Developers Some ID providers don't provide all 3 required claims Google doesn't (generally) give an e-mail Many require you to code your own default group Lots of old non-claims-aware web service code Singin’ the Custom Claim Picker blues Hard to learn / implement Laaaaaaaaaag “Exceptional circumstances”

“When Life Gives You Lemons… …don't make lemonade. Make life take the lemons back! Get mad! I don't want your damn lemons, what am I supposed to do with these? Demand to see life's manager! Make life rue the day it thought it could give Cave Johnson lemons! Do you know who I am? I'm the man who's gonna burn your house down! With the lemons! I'm gonna get my engineers to invent a combustible lemon that burns your house down!” -Cave Johnson

So if it’s So Bad, Why Use It? Using ADFS / STS with SharePoint does resolve some long standing challenges. For users, fewer accounts just makes the world a better place Can shift user account management [costs] onto others ADFS as a broker means less code, less reliance on PowerShell It also means less [re]configuration of SharePoint ADFS Proxy more secure for extranet / public facing web sites Sometimes the easiest / only way to integrate with user DB Others I haven’t even thought of…

Why Use It (cont.) Many of the problems I described have been partially or fully resolved. Migrating users – we’ve got a PowerShell for that! Can’t log out of SharePoint? We fixed that too! Proper architecture preserves access for non-claims-aware applications and tools Too many realm pickers: multiple solutions Have only 1 realm in ADFS + WinAuth or Move entirely to ADFS (no WinAuth) = get by with only 1 realm picker Use a custom solution to dynamically pick the realm

Why Use It (cont.) Development of custom claims pickers Pickers greatly simplify adding users to SharePoint Standard sources can be used by many clients and ruggedized: AD/LDAP, ASP.net SQL, PeopleSoft Truly custom pickers should receive the strongest possible reliability and performance testing Many security concerns have been mitigated SSL is not as expensive as it used to be Ability to delete cookies by logging out: user training Limit risks through proper network & server configuration

Why Use It (cont.) New capabilities are emerging rapidly: Liquid Mercury Code Solutions Log out, Realm auto-select, and Self-service cookie delete Open ID Secure Token Service – Log in to SharePoint with Google Self registration – new user profile page (in progress) Standard claims pickers (in progress) Open Source Projects on Codeplex Federation Metadata Editor thinktecture StarterSTS and IdentityServer Claims Based Identity & Access Control Guide Tools / Web Parts for FBA user management And more arriving everyday!

THANKS FOR COMING! If you liked my presentation, visit our web site at http://www.liquidmercurysolutions.com to read the multi-part companion blog series or follow us @SPLiquidMercury Real World Claims in SharePoint 2010 QUESTIONS… …or DEMO???

Thanks to Our Other Sponsors! Thanks to our Sponsors Thanks to Our Other Sponsors!

Session Evaluation Presenter: Thomas Carpe Please complete and turn in your Session Evaluation Form so we can improve future events. Survey can be filled out at: http://app.fluidsurveys.com/surveys/spstc2011-sat-s2c-104 Presenter: Thomas Carpe Session Name: Real World Claims Session No.: Sat-S2C-104