Hi,
We have a lot of externalusers which are not part of our Active Directory, but use our webapplications. I wish to store them in AD LDS and use Geneva Server as an identity provider and STS.

According to the documentation, Geneva Server supports authentication against AD LDS. The problem is that I cannot find any documumentation on how to configure Geneva Server to be an identity provider using AD LDS. All documentation and samles use AD DS.Is authentication against a AD LDS even possible in the beta 2 release?

Thanks!

According to the documentation, Geneva Server supports authentication against AD LDS.

Do the docs say that? If so, they are wrong. Geneva Server has support for pulling attributes from AD LDS stores, but it don't allow authn to be performed against AD LDS.

Is authentication against a AD LDS even possible in the beta 2 release?

Like my old boss used to say, anything possibly given enough time and money. You aren't going to get a way to do this from Microsoft in beta 2, but that doesn't mean it can't be done.

---

Regards,

Travis Spencer
http://travisspencer.com

Thank youfor your quick reply.

This document certainly seems to hint at the possibility of using AD LDS:
http://technet.microsoft.com/en-us/library/dd727951(WS.10).aspx

account store

An ActiveDirectory/ADDS or ADAM/ADLDS store that "Geneva" Server uses to authenticate users. Account stores also generate claim sets so that applications can make authorization decisions. In most situations, the account store that "Geneva" Server uses has already been deployed and is populated with users.

So does the Geneva beta 1 whitepaper:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9ca5c685-3172-4d8f-81cb-1a59bdc9f7e3&displaylang=en
Alternatively, external user account and attribute information can be stored in Active Directory Lightweight Directory Services (AD LDS). Formerly known as Active Directory Application Mode (ADAM), this technology provides a simpler directory service that’s also an option for the “Geneva�Server.

It mentions user account specifically, not only user attributes.

Too bad it isn't possible out of the box. I guess we have to build our own STS then.

My understanding is that AD LDS as an auth store is not supported under Beta 2; whether it makes a re-appearance before release is anyone's guess.

I for one would be happy to see it returned to service, since it seems that there has been a clear MSFT message around "LDS as an extranet (esp. for MOSS) auth store == good"...so it makes sense in my brain that it should remain as a viable auth store for Geneva as it was in AD FS.

---

Laura Hunter - Directory Services MVP Identity Architect - Oxford Computer Group ILM2 & Identity Training, Upcoming Dates - http://www.oxfordcomputergroup.com/course-dates.aspx

Waz,

I am in the same situation. You have to:

1. Build your own STS. The Visual Studio templates and samples help a lot to get started.
2. Configure it as an identity provider in Geneva Server.
3. Configure your AD LDS as an attribute store in Geneva Server.
4. Build claim rules as required. This may or may not be difficult depending how the structure of your directory matches up with what's possible via rules.

Not easy but not rocket science. Good luck!

JS

Too bad it isn't possible out of the box. I guess we have to build our own STS then.

Don't underestimate this task. Even if you build just an IP-STS like Jason suggested below, and federate w/ that from Geneva Server, it isn't a small job. It will take a signification amount of R&D unless you're requirments are very modest indeed. Even then, however, you will need to know quite a lot about the specs and will require a lot of help from those who have built such an application before to ensure that you end up w/ a robust product.

If you have any strings to pull at Microsoft, I would suggest yanking on them. The more of us that lobby for this feature, the more likely we are to get it.

---

Regards,

Travis Spencer
http://travisspencer.com

I really don't understand the reasoning behind pulling support for AD LDS - on a fundamental level it realy defeats the purpose of federation in the first place. By removing AD LDS, and in that case essentially removing support for LDAP in general and limiting our options to a tie in to the domain, we are left with a solution that makes it necessary to review other vendors options almost from the get-go. I really don't want to go down the path of building my own custom STS and having to worry about the low level interactions including threading, etc. I really wish someone from the product team could explain this to me and the others who will be equally bewlidered when they find this out...