Re: ADAM - SSO and provisioning considerations

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.


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


.

Relevant Pages

  • 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
    ... ADAM and "custom" security principals and gives you ... for authentication, where you might ship some default providers (ADAM LDAP ... be used to link up to the authorization store. ... > customer's identity store is a non-MS directory, ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM Hell
    ... I'd say that DNN is trying to use Windows authentication ... to bind to ADAM instead of simple bind. ... Another way to get around with would be to create a Windows user on the ADAM ...
    (microsoft.public.windows.server.active_directory)
  • Re: Authentication Using ADAM ?
    ... Those service all require Windows or Domain authentication by default, ADAM provides ADAM authentication only which is useful inside of ADAM or for applications that don't need Windows auth. ...
    (microsoft.public.windows.server.active_directory)
  • Re: About ADAM , replication and authentication.
    ... On authentication, ... To authenticate as a Windows user, you supply a username, password and ... If you have adam users, you can use just user DN and password (or SPN, ... >>> another server a replica. ...
    (microsoft.public.windows.server.active_directory)