Re: LDS user using AD Group Permissions

Hi

what kind are your LDS users? Are they native LDS user objects?
Native LDS users have no windows security context as such and so
having no meaning in a windows group, the lack of windows security context
also means that native LDS users cannot be impersonated and so
middle-tier systems might use LDS for authentication and then use
a trusted sub-system account for access to the back-end (SQL)
instance. I'm not sufficiently expert in SQL seucurity to know if
it can an external role provider for authorization.

I not clear on where in your design the authentication is done
and what security context you then use to access sql.


Lee Flight

"IT-at-IDS" <u59672@uwe> wrote in message news:a73787dbc3953@uwe...
>I have a web application in which our outside customers need access to run
> transactions (stored procs on Sql Server) on our domain. We have looked
> into
> LDS to keep these users separate from our domain. The problem we are
> having
> is allowing the LDS users the AD security rights to access these stored
> procs.
> For administration purposes we would like to use an AD group for each
> transaction (stored proc) which has access to execute. Is there a way to
> add
> LDS users to this AD group or allow them the security rights to do this.
>
> We have setup LDS and can authenicate an AD user thru to runs these
> transactions.
> LDS is running on Server 08 R2.
> AD is also Server 08 R2.
>
> Thanks.
>

Hi

can you take me through the configuration here? You are trying to restrict
access to some
stored procedures and these are called from a "web application", where does
authentication
take place: a form in the web application or is it windows intergrated
authentication for your
internal users? How is authorization to invoke the stored procedures
controlled?

In LDS you can authenticate as:

a native user which require an LDAP (simple) bind to the LDS instance to
authenticate,
that user has a security context only within LDS and so for an external
web application
you could use native users as an authentication point. A scenario here is
a standalone
LDAP directory which might be used to also store say authorization roles
if you have an application
that can leverage roles stored in an LDAP directory.

a bindProxy (user) this is a stub(by) object in LDS that requires an LDAP
bind but the
LDS bindProxy has a reference (the objectSID) to a AD DS user object and
when LDS
see the bind it uses the credentials passed to authenticate the user
against the corresponding
AD DS account (so an AD DS account must exist). A scenario here is having
user objects
in LDS but having their passwords stored in AD DS.

a windows principal (local to server running LDS or an account in a windows
domain the LDS
server has a trust realtionship with) using a secure bind. The LDS instance
uses the
secure bind authentication and attempts to verify them by normal windows
account
logon mechanisms. A scenario here is storing data in LDS but not needing to
create
user accounts within LDS to grant access to the data.

Lee Flight

Hi

"we need is a way to obtain the Domain credentials for the LDS users
to run the stored procs on the DB server"

if you are using windows security groups to secure the stored procedures
then LDS users cannot have membership of those groups. An LDS user
can have windows groups in their security context if an LDS server is domain
joined but that security context has meaning only inside LDS. Windows
security
contexts cannot "call back" to LDS to expand group membership.

If you are rolling your own application then you might be able to build up
role based access [1] and if going down that route you might want to seek
help at Joe Kaplan's directory programming forum [2].

Apologies if I have not understood your application fully.

Lee Flight
[1] http://msdn.microsoft.com/en-us/library/5k850zwb.aspx
[2] http://directoryprogramming.net/forums/default.aspx



"IT-at-IDS via WinServerKB.com" <u59672@uwe> wrote in message
news:a7cf6d6100093@uwe...
> We have 2 scenarios here both using the same approach. With one requiring
> rights to create and change permissions and the other does not need this.
> Authentication would be the same in both cases. We would like to use
> Windows
> authentication because the DB server is already part of the domain and it
> is
> easy to create a security group to each transaction (Stored Proc) and give
> access this way. The only difference is the front end. Both would use the
> same stored procs.
> 1. We would use a web server hosting a site. This site would have user
> administration capabilities with the ability to run the transactions.
> 2. The other would be Web Services also using the same DB server.
> Of course any of our employees with access work fine with LDS using proxy
> authentication.
> Our customers are the pain. Using LDS would help keep them separate (off
> the
> DC) and we could provide user account access to do the administration
> parts
> on LDS without doing delegation on the DC.
> What we need is a way to obtain the Domain credentials for the LDS users
> to
> run the stored procs on the DB server without sacrificing much. Please
> advise if you need more info. Thanks.