ADAM - SSO and provisioning considerations

[Rob Lewis]

I'm a total noob wrt security in general and AD / ADAM in particular.
That being said, I'm tasked with designing an SSO solution for our
product, and I could use some advice. There are some people in our
organization who are pushing ADAM, and I'd like to know enough to say
one way or another if ADAM can solve our problems. Based on reading
microsoft white papers and usenet posts, I have learned some things,
but not enough to make informed choices regarding system components.
That's where I'm hoping to get some help here. But first, some
background info...

Our system is a windows based client / server application. We have
multiple client apps which communicate with the server via tcp/ip.
SQL Server is our data store: all authentication & authorization data
are stored there (we use encrypted passwords).

Our current authentication model involves prompting the user for a
username / password pair. This becomes a problem for our customers
when they wish to use other applications from other vendors to get
different views on their data; they find it inconvenient to login to
each system (perhaps even with different credentials). In addition, we
haven't even consolidated authentication between our own apps.

We'd like to use some kind of SSO architecture. While I can see how
using the domain user (WIA) could be reasonably simple, that might not
be enough in all cases; particularly if 3rd party apps employ their own
authentication schemes. Here are some of our design goals:

1. SSO - user only logs in once, but can run all of our client apps (as
well as those from other vendors if possible).

2. Provision users / groups once - whatever is used as the data store,
the IT admin only creates / destroys accounts once.

3. One source for our applications to consult for authentication /
authorization.

4. Query authorized objects. In other words, once a user has been
authenticated, he can query for a list of available objects for which
he is authorized.

From what I can see, ADAM could be useful as a data store for

authentication and even group / policy / permission info as well. In
the WIA case, it could handle (1) and (3). Also, IIFP seems useful
for handling (2) above; except that we would like to be able to supply
our solution on XP Pro in some cases, and IIFP is only available on
Windows Server 2003 Enterprise Edition. For (4), I think I still need
to use SQL Server. If ADAM was in the picture, I'd have to link the
user's group SIDs to the data objects in SQL Server to be able to query
which ones he can see. Since these relationships are many to many, I'm
not sure how that could be represented efficiently in ADAM. Any ideas?

If the windows and/or domain account are not the relevant credentials,
then we need to be able to consult whatever data store is considered to
be authoritative for these apps (ours and 3rd party). This can happen
when a 3rd party app ignores the computer / domain user account and
collects its own credentials from the user, with their own backend
authentication scheme. But even if we did know where the
authentication data was stored, how could we figure out what user had
logged on to that app? Ideally, we'd like to be able to integrate
seamlessly in such situations, although I can't imagine how. Perhaps
the best we could do in this case is share the same username / password
pair with the other app, but require the user to authenticate again
(when switching apps). This is an area where my limitied knowledge has
really hit a brick wall.

Here are some more places where I'm stuck:

5. If WIA is not an option, how can I configure ADAM as an
authentication proxy to other (non-AD) LDAP compliant data stores? I'm
assuming here that we'd need to set up SSL in this case.

6. What alternatives are there to IIFP for handling (2) above?

7. If WIA *is* sufficient for our design, do I even need ADAM? Could I
just use SQL Server as our data store, get the user's SID from the
token and look up the groups & permissions in SQL? What advantage
would ADAM have over SQL in that case?

Thanks in advance!

- Rob

[Al Mulnick]

I think you hit it on the head with #7. If you use AD Authentication
(either way you would want to so that you have the same credentials), you
don't really need ADAM. In fact, if you can talk to AD, there's no need to
put ADAM on XP that I can tell from your post.

Keep in mind that ADAM is based on the same code as Active Directory. But
it doesn't have some of the NOS features such as group policy that you would
want for desktop and server management. ADAM is a distributed LDAP identity
store. Active Directory provides a LDAP identity store, an authentication
mechanism, and an auditing mechanism. You're currently using SQL like you
would Active Directory.

ADAM can be more flexibly deployed than a full-blown Active Directory
architecture, but it also has fewer abilities.

Your third party apps have to authenticate today with your application.
They call your authentication system and present credentials and prove
identity except that you store that information in SQL (hmmm....). Moving
that to AD or ADAM is not much different. Putting that into Active
Directory is often a good idea but I agree that having the overhead of IIFP
is a lot to ask especially if this needs to be a turn-key solution.

That said, I see a lot of advantages to using Active Directory as your
source identity and authentication source. I don't think I fully understand
the benefit of ADAM in that environment. I also don't understand why your
partner vendors wouldn't want to use the same built-in mechanisms, but I
have seen some occasions to use ADAM vs. AD. Most of those had to do with
schema mods vs. anything else.

Does that help? I know you can get more information about ADAM here:
http://www.microsoft.com/adam

Al

Post by Rob Lewis
I'm a total noob wrt security in general and AD / ADAM in particular.
That being said, I'm tasked with designing an SSO solution for our
product, and I could use some advice. There are some people in our
organization who are pushing ADAM, and I'd like to know enough to say
one way or another if ADAM can solve our problems. Based on reading
microsoft white papers and usenet posts, I have learned some things,
but not enough to make informed choices regarding system components.
That's where I'm hoping to get some help here. But first, some
background info...
Our system is a windows based client / server application. We have
multiple client apps which communicate with the server via tcp/ip.
SQL Server is our data store: all authentication & authorization data
are stored there (we use encrypted passwords).
Our current authentication model involves prompting the user for a
username / password pair. This becomes a problem for our customers
when they wish to use other applications from other vendors to get
different views on their data; they find it inconvenient to login to
each system (perhaps even with different credentials). In addition, we
haven't even consolidated authentication between our own apps.
We'd like to use some kind of SSO architecture. While I can see how
using the domain user (WIA) could be reasonably simple, that might not
be enough in all cases; particularly if 3rd party apps employ their own
1. SSO - user only logs in once, but can run all of our client apps (as
well as those from other vendors if possible).
2. Provision users / groups once - whatever is used as the data store,
the IT admin only creates / destroys accounts once.
3. One source for our applications to consult for authentication /
authorization.
4. Query authorized objects. In other words, once a user has been
authenticated, he can query for a list of available objects for which
he is authorized.

From what I can see, ADAM could be useful as a data store for

authentication and even group / policy / permission info as well. In
the WIA case, it could handle (1) and (3). Also, IIFP seems useful
for handling (2) above; except that we would like to be able to supply
our solution on XP Pro in some cases, and IIFP is only available on
Windows Server 2003 Enterprise Edition. For (4), I think I still need
to use SQL Server. If ADAM was in the picture, I'd have to link the
user's group SIDs to the data objects in SQL Server to be able to query
which ones he can see. Since these relationships are many to many, I'm
not sure how that could be represented efficiently in ADAM. Any ideas?
If the windows and/or domain account are not the relevant credentials,
then we need to be able to consult whatever data store is considered to
be authoritative for these apps (ours and 3rd party). This can happen
when a 3rd party app ignores the computer / domain user account and
collects its own credentials from the user, with their own backend
authentication scheme. But even if we did know where the
authentication data was stored, how could we figure out what user had
logged on to that app? Ideally, we'd like to be able to integrate
seamlessly in such situations, although I can't imagine how. Perhaps
the best we could do in this case is share the same username / password
pair with the other app, but require the user to authenticate again
(when switching apps). This is an area where my limitied knowledge has
really hit a brick wall.
5. If WIA is not an option, how can I configure ADAM as an
authentication proxy to other (non-AD) LDAP compliant data stores? I'm
assuming here that we'd need to set up SSL in this case.
6. What alternatives are there to IIFP for handling (2) above?
7. If WIA *is* sufficient for our design, do I even need ADAM? Could I
just use SQL Server as our data store, get the user's SID from the
token and look up the groups & permissions in SQL? What advantage
would ADAM have over SQL in that case?
Thanks in advance!
- Rob

[Rob Lewis]

Hi Al,

Thanks for the info. Actually, the main reason (that I know of) for
vendors not choosing AD as their authentication store has to do with
the working environment. It's the case where PC's are in public areas,
and are left logged on all the time. The user who walks up to the
machine needs to tell the application who he is in order to access his
data. For whatever reason (lazy users...), in those environments, the
user feels that it's too cumbersome to log in and out of windows.
They'd rather just launch the desired app, identify themselves, do the
work, quit and walk away. Of course, if they launch more than one app,
that's when the SSO issue arises.

I did get some clarity about the non-WIA case: as it turns out, we can
expect some level of integration with the 3rd party. In other words,
that app will launch our app, so it can pass the username or SID on the
command line and assume the user was already authenticated. Then we
just need to access our authorization data for that user.

Btw, the other reason I was given to use ADAM is to simplify our
architectural design, since if we need to support talking to different
data stores (AD, LDAP, SAM, etc), it makes sense to have our apps talk
to ADAM as a "universal" authenticator, and let ADAM deal with the rest
of the world. What I don't know is whether that's practical, or even
realistic. I'm guessing it probably is. Basically, my app needs to
bind to ADAM, passing credentials if they were supplied. If not, it
passes null credentials, binding as the domain user. Correct? The
trick appears to be getting the identity info into ADAM at the time a
user is provisioned, and telling ADAM where to go to authenticate.

FWIW, I should say that I've gotten ADAM setup on XP, gone through the
step-by-step and gotten bindProxy to work. At this point, I'm just
trying to work out a few top level details before we go to design
review.

- Rob

[Al Mulnick]

I have to say that the scenario you mention is weak at best. That and SSO
(single or simplified sign-on) does not require that the user ever logon to
the desktop OS. It does require unique credentials and can be easier with a
single credential store.

For instance, the desktop could be a kiosk (which by the sounds of it, would
be FAR more secure and in keeping with what they are doing anyway) and the
client would therefore never logon to the OS. They would however, want to
authenticate to get authorization to the data your application is holding.
Today that's done via a SQL call. Tomorrow that could be done via AD
technology. Not a major rewrite in many cases.

Post by Rob Lewis
I did get some clarity about the non-WIA case: as it turns out, we can
expect some level of integration with the 3rd party. In other words,
that app will launch our app, so it can pass the username or SID on the
command line and assume the user was already authenticated. Then we
just need to access our authorization data for that user.

You may want to look into that. It's about credentials. Passing credentials
is documented so that users can run in a certain security context.
http://msdn.microsoft.com would be a good place to look for that
information.

ADAM doesn't simplify your architecture from what I can tell in your posts.
If anything, it complicates your architecture by adding two additional
components you didn't have before. Third party apps can work just fine with
Active Directory. If they can't, then they won't work with ADAM either.
LDAP, NTLM, etc are all handled by AD. (side note: LDAP is NOT an
authentication protocol. LDAP bind is not an authentication process. It is
an identity process that may use an authentication protocol at some point.
Might make a difference later in the architecture.)

Consider it this way: in order to access a network resource, you MUST
identify, authenticate, and authorize an entity to access that resource. If
you place a proxy in front of your AD, you're just adding an additional
identification store in front of your identification store and your
authentication and authorization mechanism. What benefit does that provide?
Oh, and you would also have to synchronize that "proxy" store. Can't
imagine that would be as reliable as you'd want because you now have
introduced another moving part which goes against the KISS principle of
software architecture.

For the reasons you've mentioned, you'd need both ADAM and AD set up to
deploy a bind-proxy object. Not sure what value ADAM provides at that point
other than you would not have to modify the schema of a customer's AD
deployment. That can potentially be a barrier to a sale and you would then
be heartbroken to find out you would have to rearchitect. The customer also
may not be happy to find out they have to deploy your app, sql, Windows 2003
Enterprise, ADAM, etc AND that they have to configure it, maintain it, etc.
I wouldn't be happy about that.

I would be happier if I had the OPTION to deploy this against ADAM or AD,
but I would not be happy to be forced to deploy both if it otherwise made no
sense. I'd likely laugh the sales team out of my office (if I had one any
more ;) and go look at the competition.

My $0.04 anyway.

Al

Post by Rob Lewis
Hi Al,
Thanks for the info. Actually, the main reason (that I know of) for
vendors not choosing AD as their authentication store has to do with
the working environment. It's the case where PC's are in public areas,
and are left logged on all the time. The user who walks up to the
machine needs to tell the application who he is in order to access his
data. For whatever reason (lazy users...), in those environments, the
user feels that it's too cumbersome to log in and out of windows.
They'd rather just launch the desired app, identify themselves, do the
work, quit and walk away. Of course, if they launch more than one app,
that's when the SSO issue arises.
I did get some clarity about the non-WIA case: as it turns out, we can
expect some level of integration with the 3rd party. In other words,
that app will launch our app, so it can pass the username or SID on the
command line and assume the user was already authenticated. Then we
just need to access our authorization data for that user.
Btw, the other reason I was given to use ADAM is to simplify our
architectural design, since if we need to support talking to different
data stores (AD, LDAP, SAM, etc), it makes sense to have our apps talk
to ADAM as a "universal" authenticator, and let ADAM deal with the rest
of the world. What I don't know is whether that's practical, or even
realistic. I'm guessing it probably is. Basically, my app needs to
bind to ADAM, passing credentials if they were supplied. If not, it
passes null credentials, binding as the domain user. Correct? The
trick appears to be getting the identity info into ADAM at the time a
user is provisioned, and telling ADAM where to go to authenticate.
FWIW, I should say that I've gotten ADAM setup on XP, gone through the
step-by-step and gotten bindProxy to work. At this point, I'm just
trying to work out a few top level details before we go to design
review.
- Rob

[Rob Lewis]

I appreciate the words of wisdom. I'm almost there...but not quite :-(
I'm sorry if I'm coming across as thick, but as I said, I'm a noob.
Also, I'm not sure how clear I was about the fact that we are selling a
product into the market, and that we are considering packaging ADAM
with that product. We can't do that with AD; and we can't rely on all
of our customers using AD as their identity store...not all of them do.

In addition, we want to enhance the schema (by adding our own security
groups among other things). Being a vendor, it's impossible for us to
access or modify the customer's AD schema. That's one place ADAM may
fit in.

But none of that amounts to much unless we can configure ADAM as the
"guy who talks to the rest of the world" for authentication. That's
the really important part.

In the case where "the rest of the world" is AD, then I can see how to
make ADAM do that. But what about the case where the customer is using
some other identity store / authentication mechanism? (A) Can ADAM be
configured to handle the authentication part in that case? And more
importantly, (B) How?

Anyone from Microsoft care to chime in? Thanks again!

- Rob

[Al Mulnick]

I can't speak for the Microsoft folks ;)

However,
some thoughts come to mind:
"We can't do that with AD; and we can't rely on all
of our customers using AD as their identity store...not all of them do."

That's true. I agree with that wholeheartedly. However, if you don't have
AD or otherwise can't count on AD being there, then I don't think you can
count on using bind-proxy objects right? Those rely on AD being present. In
that case, then you have the traditional ldap bind to work with. That's
about it from what I can tell.

As for the other vendors using those credentials, you either have to share
the credential store as your authentication source, else you have to
instruct your third party vendors how to query the credentials in your
world.

There is no magic bullet for authentication and SSO because not everyone in
your ecosystem are going to use the same source or deploy a source that
trusts yours (which I suppose is really a third option to have them proxy
their requests to your subsystem and then get authentication from your
system.)

Basically, if the apps don't all share an authentication system, then you'll
need to circumvent that. That's technology agnostic architecture IMHO.

Al

Post by Rob Lewis
I appreciate the words of wisdom. I'm almost there...but not quite :-(
I'm sorry if I'm coming across as thick, but as I said, I'm a noob.
Also, I'm not sure how clear I was about the fact that we are selling a
product into the market, and that we are considering packaging ADAM
with that product. We can't do that with AD; and we can't rely on all
of our customers using AD as their identity store...not all of them do.
In addition, we want to enhance the schema (by adding our own security
groups among other things). Being a vendor, it's impossible for us to
access or modify the customer's AD schema. That's one place ADAM may
fit in.
But none of that amounts to much unless we can configure ADAM as the
"guy who talks to the rest of the world" for authentication. That's
the really important part.
In the case where "the rest of the world" is AD, then I can see how to
make ADAM do that. But what about the case where the customer is using
some other identity store / authentication mechanism? (A) Can ADAM be
configured to handle the authentication part in that case? And more
importantly, (B) How?
Anyone from Microsoft care to chime in? Thanks again!
- Rob

[Rob Lewis]

Al - thanks for your patience...hopefully the Microsoft folx will chip
in when the have the time (this thread is less than 24 hrs old) :-)

Ok. I can live with traditional ldap bind, but I guess what I'm trying
to ask is, can ADAM be configured to transparently refer these bind
requests? In other words, I log into ADAM by supplying username and
password (using simple ldap bind), and based on prior configuration,
ADAM talks to somebody else (not AD), and then ADAM comes back with,
"yeah, you are who you say you are". I don't want to have to chase the
referrals; I want ADAM to do it for me.

It may be that ADAM is perfect for that. Or maybe it's completely the
wrong thing...I don't know. I'm being told (by people who *don't*
know) that it can. But after reading the docs, I can't verify to my
satisfaction that it can. I need to be sure! If it can, then I'm the
one who has to make it work. If not, I'm happy to save myself the pain
of trying to figure it out only to find out later that it can't be done
with ADAM.

By the way, sorry if the language I'm using is imprecise. It's based
only on the reading that I've done...not on any actual experience with
security stuff (I don't have any of that!).

- Rob

[Joe Kaplan (MVP - ADSI)]

ADAM can authenticate users these ways:
- It can authenticate an ADAM user in the ADAM store via a simple bind (or
digest bind if your client supports that and you have the newest version
(SP1 for 2k3 I think))
- It can authenticate a Windows user via "pass through" authentication
using a secure bind
- It can authenticate a Windows user via simple bind with a bindProxy
object that points to a Windows user by its SID

It does not proxy any other directories.

Thus, you cannot use it as an authentication mechanism for users in a non-MS
directory unless you come up with some sort of an account/password sync
process to get the users into the ADAM store (which is not really
authenticating the user in the other directory anymore).

HTH,

Joe K.

Post by Rob Lewis
Al - thanks for your patience...hopefully the Microsoft folx will chip
in when the have the time (this thread is less than 24 hrs old) :-)
Ok. I can live with traditional ldap bind, but I guess what I'm trying
to ask is, can ADAM be configured to transparently refer these bind
requests? In other words, I log into ADAM by supplying username and
password (using simple ldap bind), and based on prior configuration,
ADAM talks to somebody else (not AD), and then ADAM comes back with,
"yeah, you are who you say you are". I don't want to have to chase the
referrals; I want ADAM to do it for me.
It may be that ADAM is perfect for that. Or maybe it's completely the
wrong thing...I don't know. I'm being told (by people who *don't*
know) that it can. But after reading the docs, I can't verify to my
satisfaction that it can. I need to be sure! If it can, then I'm the
one who has to make it work. If not, I'm happy to save myself the pain
of trying to figure it out only to find out later that it can't be done
with ADAM.
By the way, sorry if the language I'm using is imprecise. It's based
only on the reading that I've done...not on any actual experience with
security stuff (I don't have any of that!).
- Rob

[Rob Lewis]

Thanks Joe! That's exactly what I needed to know.

As far as account/password sync goes: I agree - not a good solution.
Especially since it would need to be a custom job for each different
store / authentication scheme.

That leaves me in a bit of a bind though (no pun intended). If not
ADAM, then what? :-(

I suppose another way to go would be to go ahead with ADAM, but if the
customer's identity store is a non-MS directory, then they will have to
get the accounts into ADAM and live with multiple identity stores and
all that that involves...that scenario is far better than what we have
now. And I'm guessing that the majority of our customers use AD.

Thanks for all the advice!

- Rob

[Joe Kaplan (MVP - ADSI)]

There are other things you might want to consider too. For example, if your
needs for a directory are primarily authorization-related (need application
specific groups and such), you might want to consider using AzMan as the
core of your authorization architecture.

AzMan supports Windows, ADAM and "custom" security principals and gives you
a lot of flexibility there.

Another aspect of this would be to support some kind of a plugin framework
for authentication, where you might ship some default providers (ADAM LDAP
bind, using the existing Windows user's security context, LDAP bind to AD,
SSPI to AD/Windows, LDAP bind to other directory, etc.), with the ability to
allow the customers and third parties to add their own authentication
providers. That way, if you end up needing to support something like smart
cards or RSA SecurID tokens or something, a plugin approach could be used.
Once the user is authenticated, then the user's authenticated identity would
be used to link up to the authorization store.

Another thing to consider is the federated model I talked about in my other
post with ADFS and similar technologies (SAML, etc.). Getting up to speed
on that stuff will probably help you make better design decisions about how
to proceed.

Best of luck,

Joe K.

Post by Rob Lewis
Thanks Joe! That's exactly what I needed to know.
As far as account/password sync goes: I agree - not a good solution.
Especially since it would need to be a custom job for each different
store / authentication scheme.
That leaves me in a bit of a bind though (no pun intended). If not
ADAM, then what? :-(
I suppose another way to go would be to go ahead with ADAM, but if the
customer's identity store is a non-MS directory, then they will have to
get the accounts into ADAM and live with multiple identity stores and
all that that involves...that scenario is far better than what we have
now. And I'm guessing that the majority of our customers use AD.
Thanks for all the advice!
- Rob

[Joe Kaplan (MVP - ADSI)]

This whole problem you are trying to solve is pretty hard because your
application seems to require its own identity store of some sort. That
makes it a complex undertaking for anyone to use your application because
they need a way to use their existing identity store in concert with yours.
This generally implies some sort of sync process.

ADAM is a nice choice for a Windows-based app because it is easy to package,
has nice AD integration features and scales well, but you still have an
identity integration problem.

Ideally, your app would be designed so that it can leverage an external
identity store completely and not need a copy of each identity in your own
system for custom groups and schema. That eliminates the sync issue. Doing
something like what Microsoft is doing with ADFS and "claims-aware"
applications is actually a good idea for a design pattern here. It probably
doesn't solve everything, but it is worth looking at for ideas.

You could still bundle ADAM as a default identity store for customers that
don't have a central store or don't want to try to leverage it.

Just some ideas,

Joe K.

Post by Rob Lewis
I appreciate the words of wisdom. I'm almost there...but not quite :-(
I'm sorry if I'm coming across as thick, but as I said, I'm a noob.
Also, I'm not sure how clear I was about the fact that we are selling a
product into the market, and that we are considering packaging ADAM
with that product. We can't do that with AD; and we can't rely on all
of our customers using AD as their identity store...not all of them do.
In addition, we want to enhance the schema (by adding our own security
groups among other things). Being a vendor, it's impossible for us to
access or modify the customer's AD schema. That's one place ADAM may
fit in.
But none of that amounts to much unless we can configure ADAM as the
"guy who talks to the rest of the world" for authentication. That's
the really important part.
In the case where "the rest of the world" is AD, then I can see how to
make ADAM do that. But what about the case where the customer is using
some other identity store / authentication mechanism? (A) Can ADAM be
configured to handle the authentication part in that case? And more
importantly, (B) How?
Anyone from Microsoft care to chime in? Thanks again!
- Rob

[Rob Lewis]

Thanks Joe. You're right - a central problem here is: where are
identities stored. What if we use ADAM, but don't store the identities
at all; they are all in the customer's identity store. If that store
is AD, then no problem. But what if it's not AD? In that case, can we
use ADAM to transparently refer the ldap binds? Don't know if that's
possible...that's what I'm trying to figure out. If not, then I don't
think we can use ADAM.

Actually, to fine-tune what it is we're actually trying to do, it's
mostly this: the customer already has an identity store (with thousands
of users, let's say). When they install our product, their users
should be able to use their existing user accounts (and credentials) to
access their data in our app (as opposed to having them recreate
thousands of accounts on our system).

The reason we need our own groups is: admin users of our product can
create new groups using our app, and alter membership in those groups.
But since they have nothing to do with the organization's global
structure, they can't go in AD (or anywhere else outside of our
product). However, we don't need to use ADAM for that. It would be
nice if we could wrap group membership and authentication together, but
I see the group membership problem as much easier to solve. We could
continue to use our SQL database for that; especially since our admin
users must manually manipulate these memberships anyway.

It's the authentication problem that's got me scratching my head...

- Rob

[Joe Kaplan (MVP - ADSI)]

In this situation, you could use ADAM. Essentially, you would use a secure
bind to ADAM and passthrough authentication to AD in order to do the
authentication. You could even leverage the built in Windows SSO stuff this
way. The secure bind mechanism supports supplied credentials or using the
current Windows security context directly.

You can also create groups in ADAM and add Windows users to them, so that
might be a good way to solve the groups problem.

You could also leverage ADAM to store user principals that don't have a
Windows counterpart, perhaps for customers that want to create completely
separate identities or can't leverage Windows.

Really, the only problem with this would be supporting other identity stores
besides Windows and ADAM. That would most certainly require synch or a
different solution.

Joe K.

Post by Rob Lewis
Thanks Joe. You're right - a central problem here is: where are
identities stored. What if we use ADAM, but don't store the identities
at all; they are all in the customer's identity store. If that store
is AD, then no problem. But what if it's not AD? In that case, can we
use ADAM to transparently refer the ldap binds? Don't know if that's
possible...that's what I'm trying to figure out. If not, then I don't
think we can use ADAM.
Actually, to fine-tune what it is we're actually trying to do, it's
mostly this: the customer already has an identity store (with thousands
of users, let's say). When they install our product, their users
should be able to use their existing user accounts (and credentials) to
access their data in our app (as opposed to having them recreate
thousands of accounts on our system).
The reason we need our own groups is: admin users of our product can
create new groups using our app, and alter membership in those groups.
But since they have nothing to do with the organization's global
structure, they can't go in AD (or anywhere else outside of our
product). However, we don't need to use ADAM for that. It would be
nice if we could wrap group membership and authentication together, but
I see the group membership problem as much easier to solve. We could
continue to use our SQL database for that; especially since our admin
users must manually manipulate these memberships anyway.
It's the authentication problem that's got me scratching my head...
- Rob

[Al Mulnick]

Agreed, although I wonder what the implication would be if you used AD as
the authentication store for the user and groups in SQL for the
authorization?
Is that possible with your product?

I know a little while back I did some work with a company that wanted to
install an OU, do LDAP bind's to AD for authentication, and used some
middleware components to sit between. Wasn't elegant, but they were nice
enough not to extend the schema so I was very willing to go along. It was an
OU and a bunch of groups that they used to permit access to their resources.
I bring this up as an example of how you *could* do this. They were porting
that application from SunOne directories, so there were a few issues, but
nothing unexpected.

The above illustrates why you don't need ADAM. We didn't need ADAM because
there was no need to proxy the directory or the authentication mechanism.
Just the authorization portion of the transaction needed to be different. In
there case, they saw no reason to put that into a separate DB. I don't see
one here either.

What your application does with the information it collects is up to you.
Making it work with AD, ADAM, SunOne, OpenLDAP etc is all possible and would
be fairly consistent with some extra effort. I don't think your clients are
going to mind if you do that, as long as you don't require schema
extensions. If you do, then some will be OK and some won't but for just
about all it will increase the barrier to entry for your sales team and
cause a weakness where your competition can get a toe-hold in your accounts.

I think you're going down the wrong path if you think you're going to walk
into an account and architect a SSO solution for their identity stores and
the third-party applications they buy. You may be able to create an
ecosystem that third-party vendors choose to plug-in to and use as many open
protocols as possible, but you would be nutz if you think you can solve this
problem for them and the customers. Really, you'd be nutz if you created
this solution and didn't sell it as a solution in and of itself.

I see nothing in your posts that indicate you cannot use just about any LDAP
store for your identity store. In some you'll also get SSO like qualities.
Like AD. ADAM buys you nothing but complexity that I can see as long as you
don't need to modify the schema. If you do, it could offer an alternative
to some.

Al Mulnick -MVP Directory Services

Post by Joe Kaplan (MVP - ADSI)
In this situation, you could use ADAM. Essentially, you would use a
secure bind to ADAM and passthrough authentication to AD in order to do
the authentication. You could even leverage the built in Windows SSO
stuff this way. The secure bind mechanism supports supplied credentials
or using the current Windows security context directly.
You can also create groups in ADAM and add Windows users to them, so that
might be a good way to solve the groups problem.
You could also leverage ADAM to store user principals that don't have a
Windows counterpart, perhaps for customers that want to create completely
separate identities or can't leverage Windows.
Really, the only problem with this would be supporting other identity
stores besides Windows and ADAM. That would most certainly require synch
or a different solution.
Joe K.

Post by Rob Lewis
Thanks Joe. You're right - a central problem here is: where are
identities stored. What if we use ADAM, but don't store the identities
at all; they are all in the customer's identity store. If that store
is AD, then no problem. But what if it's not AD? In that case, can we
use ADAM to transparently refer the ldap binds? Don't know if that's
possible...that's what I'm trying to figure out. If not, then I don't
think we can use ADAM.
Actually, to fine-tune what it is we're actually trying to do, it's
mostly this: the customer already has an identity store (with thousands
of users, let's say). When they install our product, their users
should be able to use their existing user accounts (and credentials) to
access their data in our app (as opposed to having them recreate
thousands of accounts on our system).
The reason we need our own groups is: admin users of our product can
create new groups using our app, and alter membership in those groups.
But since they have nothing to do with the organization's global
structure, they can't go in AD (or anywhere else outside of our
product). However, we don't need to use ADAM for that. It would be
nice if we could wrap group membership and authentication together, but
I see the group membership problem as much easier to solve. We could
continue to use our SQL database for that; especially since our admin
users must manually manipulate these memberships anyway.
It's the authentication problem that's got me scratching my head...
- Rob

[Joe Kaplan (MVP - ADSI)]

Yep, I'm agreeing with Al as well here.

Joe K.

Post by Al Mulnick
Agreed, although I wonder what the implication would be if you used AD as
the authentication store for the user and groups in SQL for the
authorization?
Is that possible with your product?
I know a little while back I did some work with a company that wanted to
install an OU, do LDAP bind's to AD for authentication, and used some
middleware components to sit between. Wasn't elegant, but they were nice
enough not to extend the schema so I was very willing to go along. It was
an OU and a bunch of groups that they used to permit access to their
resources. I bring this up as an example of how you *could* do this. They
were porting that application from SunOne directories, so there were a few
issues, but nothing unexpected.
The above illustrates why you don't need ADAM. We didn't need ADAM
because there was no need to proxy the directory or the authentication
mechanism. Just the authorization portion of the transaction needed to be
different. In there case, they saw no reason to put that into a separate
DB. I don't see one here either.
What your application does with the information it collects is up to you.
Making it work with AD, ADAM, SunOne, OpenLDAP etc is all possible and
would be fairly consistent with some extra effort. I don't think your
clients are going to mind if you do that, as long as you don't require
schema extensions. If you do, then some will be OK and some won't but for
just about all it will increase the barrier to entry for your sales team
and cause a weakness where your competition can get a toe-hold in your
accounts.
I think you're going down the wrong path if you think you're going to walk
into an account and architect a SSO solution for their identity stores and
the third-party applications they buy. You may be able to create an
ecosystem that third-party vendors choose to plug-in to and use as many
open protocols as possible, but you would be nutz if you think you can
solve this problem for them and the customers. Really, you'd be nutz if
you created this solution and didn't sell it as a solution in and of
itself.
I see nothing in your posts that indicate you cannot use just about any
LDAP store for your identity store. In some you'll also get SSO like
qualities. Like AD. ADAM buys you nothing but complexity that I can see
as long as you don't need to modify the schema. If you do, it could offer
an alternative to some.
Al Mulnick -MVP Directory Services