Re: ADAM - SSO and provisioning considerations

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



"Rob Lewis" <roblewis5@xxxxxxxxx> wrote in message
news:1123173638.902000.130200@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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
>


.

Relevant Pages

  • ADAM - SSO and provisioning considerations
    ... I'm a total noob wrt security in general and AD / ADAM in particular. ... multiple client apps which communicate with the server via tcp/ip. ... SQL Server is our data store: all authentication & authorization data ... Provision users / groups once - whatever is used as the data store, ...
    (microsoft.public.windows.server.active_directory)
  • Re: adam bind-redirect
    ... a third party doing authentication) then the proxy-redirect isnt an option. ... could benefit from bind redirect/User Proxy Object ... >> Our Adam will have a user store where we put custom user attributes. ... > Integrated authentication gives you a Windows security context ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM - SSO and provisioning considerations
    ... single credential store. ... > that app will launch our app, so it can pass the username or SID on the ... ADAM doesn't simplify your architecture from what I can tell in your posts. ... LDAP bind is not an authentication process. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Use of Active Directory vs Database (e.g. SQL server)
    ... the main reason to use ADAM for authentication is that it ... If you go with SQL for the user store, you have to build all that. ... the app going to have its own SQL server database for OLTP ...
    (microsoft.public.windows.server.active_directory)
  • Re: Random logon failure with ADAM Bind Proxy
    ... There was a similar problem discussed here a while ago, see "ADAM user ... I have been using ADAM bind proxy to authenticate users against AD. ... a.ADAM bindproxy authentication was working fine. ... DirectoryEntry user = new DirectoryEntry(userDN, ...
    (microsoft.public.windows.server.active_directory)