Tuesday, February 22, 2011 11:42 AM
I must admit I was stunned when I did my research and found out that ADFS v2 only supports AD and does not support AD LDS any more as I, like all the other posters I saw, consider AD LDS the correct technology to use in a number of scenarios where AD is definitely not a fit. I have also seen a number of workarounds, including using an ADFS v1 server as a trusted party.
It is impossible to gauge the demand for this feature (i.e. making ADFS support AD LDS again, or even another account store like SQL, although AD LDS is the most likely!), but I would have thought that it would be fairly high considering the fact that all the articles and docs I have seen make it seem as though AD LDS is considered a fairly strategic component by Microsoft. They have also presumably considered it to some degree based on the fact it was present in ADFS v1 - I have not seen any explanation for why it was pulled but can imagine it was down to resource or time as opposed to it being determined unecessary (quite happy for someone to enlighten me on this if they know for sure what the reason was!).
So - does anyone know whether this feature will ever make it back into ADFS?
Tuesday, February 22, 2011 5:05 PMShort answer - probably not. My guess is beccause Microsoft doesn't want to be in the position of taking responsibility of the security of your custom code. ADFS v2 was a complete rewrite over ADFS v1, and they wanted to streamline what the product actually does. It is supposed to be a STS for AD. Nothing more, nothing less.
Tuesday, February 22, 2011 5:36 PM
Apologies in advance if I am wrong about this as I am a bit of a beginner with ADFS et al - I don't see where there would be any custom code then using AD LDS and I wouldn't want any anyway. It is plumbing that hooks ADFS into AD and I would expect it to be the same for AD LDS. Is that not the case?
Tuesday, February 22, 2011 6:26 PM
Yes and no. With AD LDS there is a lot of stuff that just isn't there like you have with AD. IMO, I don't think AD LDS was designed to act as a credential store. It was designed as an information store for applications that should have no business storing their identity metadata in Active Directory. While you can store credentials, things start getting hinky around the management of the them. There are no OOTB applications to manage the data, like AD Users MMC.
To further explain my original answer, I don't think Microsoft wanted to support a second credential store. They already have Active Directory. It would have muddied the scope of the product.
Tuesday, February 22, 2011 7:03 PM
The thing is, even without the management side, AD LDS has its place exactly where you mentioned - as a store for applications. It also is very useful in that it is built on AD tech so migrating to AD is easy, should that happen at some point.
Basically, there are a number of scenarios where AD simply isn't viable for a lot of places and LDS fills that need - if it didn't then it wouldn't have been around for so long as ADAM, it would have been dropped.
But I don't want to talk about the relative merits of LDS as I know for sure that is one which will divide everyone! My point is that it currently is being offered by MS to fill the gap that AD cannot fill and therefore, I think it is fair to ask if it will ever receive support in ADFS. Especially since someone there felt there was justification for doing the work to include it in ADFS v1.
If it is not to ever be supported, then it would be nice to get an official justification but I realise that might be asking too much ......
Monday, February 28, 2011 8:58 PM
I agree with Dan0001! ADLDS has been a credential store since ADAM days, was supported in ADFS v1 and now dropped in ADFS v2! Just doesn't sound like there is a collaborative effort within the various product teams at Microsoft.
Tuesday, March 01, 2011 7:56 PMoh well, ok I will let this one die then as it seems no-one is either able to answer or allowed to answer - bit of a shame really as I am sure there are a number of people wondering the same thing. next stop, pingfederate ....
Saturday, March 03, 2012 4:30 PMAt TEC 2010 Joe Kaplan spoke on how he created an STS for AD LDS by building on a codeplex project started by ThinkTecture: http://startersts.codeplex.com/
David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html
Wednesday, April 11, 2012 2:52 PM
It's one year later, but I want to say that I fully agree with Dan0001. This should be built into ADFS v2. I've seen a lot of example where AD LDS is used to store credentials, not just some app-specific information.
Wednesday, April 11, 2012 6:35 PM
Not to sound pedantic :), but... no, it really shouldn't. ADFS is a fully functioning STS that works with it's fully functioning counterpart - Active Directory. AD LDS is not a viable product on it's own because it really doesn't do anything until you start plugging in custom code (or third party code, etc).
Having one single STS to handle every single credential store is a bit backwards. You should have an STS for each credential store. That's kind of the whole point. If Microsoft did support AD LDS as a credential store for an STS then they really should create a new STS.
Developer Security MVP | www.syfuhs.net
Tuesday, April 17, 2012 2:49 PM
There is some additional information on my blog regarding this topic: http://virtualdirectory.wordpress.com/2012/04/17/extending-adfs-to-multiple-identity-and-attribute-stores-part-1-of-2-the-basics/