Auteur de questions
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?
Danmardi 22 février 2011 11:42
Toutes les réponses
Short 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.mardi 22 février 2011 17:05
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?
Danmardi 22 février 2011 17:36
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.mardi 22 février 2011 18:26
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 ......mardi 22 février 2011 19:03
At 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.htmlsamedi 3 mars 2012 16:30
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.netmercredi 11 avril 2012 18:35
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/mardi 17 avril 2012 14:49