|
|
|
date: Mon, 7 Apr 2008 17:22:01 -0700,
group: microsoft.public.dotnet.security
back
Validate user permission
I'm working on building a web-based solution (c# + .net) to allow users to
manage AD groups that they have appropriate rights to manage. On all groups
in Active Directory, there is an advanced permission called "Write Members".
If the user (who logged in via a forms based login page) is granted that
permission on the group (either directly or by being a member of a group that
has been granted the necessary permission), they should be able to update the
group membership. The web app has its own user account with enough
permissions to update the group, but I don't know the best way of having it
determine if it should use it's powers to update the membership for the user.
My question: What is the best way to handle this, and is there a way for me
to just pass the user DN (or SID, SAMAccountName, etc), and have AD determine
if it that user is allowed to access that object.
I've found code that should be able to get the user's security token, and
parse the SIDs it contains. I'm assuming I could then take that list of
SIDs, and compare it to the list of users/groups that have Write Members set
to allow on the group in question. This seems ugly/wrong. There are too
many cases where this falls short (i.e. the user is a member of a group that
doesn't have the Write Members permission, but it does have the Write All
Properties permission. It also doesn't effectively check for deny entries.)
It feels like there should be a way for me to simply [programatically] ask AD
if user X has access to update the "member" attribute on a given group.
I am a Systems Engineer and not (yet) a programmer, so a little more verbose
answer is very much appreciated.
Thanks!
date: Mon, 7 Apr 2008 17:22:01 -0700
author: Dan
Re: Validate user permission
The best way to do this is to not use forms authentication but to use
Windows auth so that you can use the user's security context to talk to AD
directly.
If you bind to the directory using the credentials of the actual user, it is
much easier to apply their actual permissions in the directory. You can do
things like use the allowedAttributesEffective attribute to determine if the
authenticated user can modify a given attribute (member is the one you are
interested in, which is the only attribute in the Write Members permission
set).
You really really don't to attempt to recompute the DACL yourself. That is
very complicated. You should let AD do it for you.
If you must use forms auth, you should capture the user's credentials and
use those to bind to AD so that you can still take advantage of the native
permissions. Using the service account to access the directory isn't the
way to go here.
If you wanted to apply a different security model than that imposed by the
directory itself (a trusted subsystem architecture), then it would make
sense to use the service account for modifications and manage the
permissions in your business logic, but since you want to use the native AD
permissions, use the native security.
I would definitely recommend using the new
System.DirectoryServices.AccountManagement namespace in .NET 3.5 if you can.
It makes the actual group membership manipulation very easy to do.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Dan" wrote in message
news:4097FB1A-85F8-4BC7-95D9-2C578A295D7C@microsoft.com...
> I'm working on building a web-based solution (c# + .net) to allow users to
> manage AD groups that they have appropriate rights to manage. On all
> groups
> in Active Directory, there is an advanced permission called "Write
> Members".
> If the user (who logged in via a forms based login page) is granted that
> permission on the group (either directly or by being a member of a group
> that
> has been granted the necessary permission), they should be able to update
> the
> group membership. The web app has its own user account with enough
> permissions to update the group, but I don't know the best way of having
> it
> determine if it should use it's powers to update the membership for the
> user.
>
>
> My question: What is the best way to handle this, and is there a way for
> me
> to just pass the user DN (or SID, SAMAccountName, etc), and have AD
> determine
> if it that user is allowed to access that object.
>
> I've found code that should be able to get the user's security token, and
> parse the SIDs it contains. I'm assuming I could then take that list of
> SIDs, and compare it to the list of users/groups that have Write Members
> set
> to allow on the group in question. This seems ugly/wrong. There are too
> many cases where this falls short (i.e. the user is a member of a group
> that
> doesn't have the Write Members permission, but it does have the Write All
> Properties permission. It also doesn't effectively check for deny
> entries.)
> It feels like there should be a way for me to simply [programatically] ask
> AD
> if user X has access to update the "member" attribute on a given group.
>
> I am a Systems Engineer and not (yet) a programmer, so a little more
> verbose
> answer is very much appreciated.
>
> Thanks!
date: Mon, 7 Apr 2008 22:20:15 -0500
author: Joe Kaplan
Re: Validate user permission
Thanks a lot for the reply Joe! I'll definitely look into re-doing how I was
planning to handle this, you're right that it makes more sense to let AD make
the decision (I was just hesitant to figure out how to do that....) GREAT
book by the way. It's already came in handy a few times on what I'm trying
to accomplish here.
Thanks again,
Dan
"Joe Kaplan" wrote:
> The best way to do this is to not use forms authentication but to use
> Windows auth so that you can use the user's security context to talk to AD
> directly.
>
> If you bind to the directory using the credentials of the actual user, it is
> much easier to apply their actual permissions in the directory. You can do
> things like use the allowedAttributesEffective attribute to determine if the
> authenticated user can modify a given attribute (member is the one you are
> interested in, which is the only attribute in the Write Members permission
> set).
>
> You really really don't to attempt to recompute the DACL yourself. That is
> very complicated. You should let AD do it for you.
>
> If you must use forms auth, you should capture the user's credentials and
> use those to bind to AD so that you can still take advantage of the native
> permissions. Using the service account to access the directory isn't the
> way to go here.
>
> If you wanted to apply a different security model than that imposed by the
> directory itself (a trusted subsystem architecture), then it would make
> sense to use the service account for modifications and manage the
> permissions in your business logic, but since you want to use the native AD
> permissions, use the native security.
>
> I would definitely recommend using the new
> System.DirectoryServices.AccountManagement namespace in .NET 3.5 if you can.
> It makes the actual group membership manipulation very easy to do.
>
> Joe K.
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> --
> "Dan" wrote in message
> news:4097FB1A-85F8-4BC7-95D9-2C578A295D7C@microsoft.com...
> > I'm working on building a web-based solution (c# + .net) to allow users to
> > manage AD groups that they have appropriate rights to manage. On all
> > groups
> > in Active Directory, there is an advanced permission called "Write
> > Members".
> > If the user (who logged in via a forms based login page) is granted that
> > permission on the group (either directly or by being a member of a group
> > that
> > has been granted the necessary permission), they should be able to update
> > the
> > group membership. The web app has its own user account with enough
> > permissions to update the group, but I don't know the best way of having
> > it
> > determine if it should use it's powers to update the membership for the
> > user.
> >
> >
> > My question: What is the best way to handle this, and is there a way for
> > me
> > to just pass the user DN (or SID, SAMAccountName, etc), and have AD
> > determine
> > if it that user is allowed to access that object.
> >
> > I've found code that should be able to get the user's security token, and
> > parse the SIDs it contains. I'm assuming I could then take that list of
> > SIDs, and compare it to the list of users/groups that have Write Members
> > set
> > to allow on the group in question. This seems ugly/wrong. There are too
> > many cases where this falls short (i.e. the user is a member of a group
> > that
> > doesn't have the Write Members permission, but it does have the Write All
> > Properties permission. It also doesn't effectively check for deny
> > entries.)
> > It feels like there should be a way for me to simply [programatically] ask
> > AD
> > if user X has access to update the "member" attribute on a given group.
> >
> > I am a Systems Engineer and not (yet) a programmer, so a little more
> > verbose
> > answer is very much appreciated.
> >
> > Thanks!
>
>
date: Wed, 9 Apr 2008 16:17:00 -0700
author: Dan
Re: Validate user permission
Thanks for the kind words on the book. I hope it serves you well.
Since you have it, I think the allowedAttributesEffective sample is actually
in ch 7 instead of ch 8 (where it might have made more sense), as we
sandwiched it in to a discussion about schema where we were showing how to
find all the available attributes for a given object using
allowedAttributes.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Dan" wrote in message
news:2BBFB415-17E7-4BF4-8606-047B2BC535D7@microsoft.com...
> Thanks a lot for the reply Joe! I'll definitely look into re-doing how I
> was
> planning to handle this, you're right that it makes more sense to let AD
> make
> the decision (I was just hesitant to figure out how to do that....) GREAT
> book by the way. It's already came in handy a few times on what I'm
> trying
> to accomplish here.
>
> Thanks again,
> Dan
>
> "Joe Kaplan" wrote:
>
>> The best way to do this is to not use forms authentication but to use
>> Windows auth so that you can use the user's security context to talk to
>> AD
>> directly.
>>
>> If you bind to the directory using the credentials of the actual user, it
>> is
>> much easier to apply their actual permissions in the directory. You can
>> do
>> things like use the allowedAttributesEffective attribute to determine if
>> the
>> authenticated user can modify a given attribute (member is the one you
>> are
>> interested in, which is the only attribute in the Write Members
>> permission
>> set).
>>
>> You really really don't to attempt to recompute the DACL yourself. That
>> is
>> very complicated. You should let AD do it for you.
>>
>> If you must use forms auth, you should capture the user's credentials and
>> use those to bind to AD so that you can still take advantage of the
>> native
>> permissions. Using the service account to access the directory isn't the
>> way to go here.
>>
>> If you wanted to apply a different security model than that imposed by
>> the
>> directory itself (a trusted subsystem architecture), then it would make
>> sense to use the service account for modifications and manage the
>> permissions in your business logic, but since you want to use the native
>> AD
>> permissions, use the native security.
>>
>> I would definitely recommend using the new
>> System.DirectoryServices.AccountManagement namespace in .NET 3.5 if you
>> can.
>> It makes the actual group membership manipulation very easy to do.
>>
>> Joe K.
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> --
>> "Dan" wrote in message
>> news:4097FB1A-85F8-4BC7-95D9-2C578A295D7C@microsoft.com...
>> > I'm working on building a web-based solution (c# + .net) to allow users
>> > to
>> > manage AD groups that they have appropriate rights to manage. On all
>> > groups
>> > in Active Directory, there is an advanced permission called "Write
>> > Members".
>> > If the user (who logged in via a forms based login page) is granted
>> > that
>> > permission on the group (either directly or by being a member of a
>> > group
>> > that
>> > has been granted the necessary permission), they should be able to
>> > update
>> > the
>> > group membership. The web app has its own user account with enough
>> > permissions to update the group, but I don't know the best way of
>> > having
>> > it
>> > determine if it should use it's powers to update the membership for the
>> > user.
>> >
>> >
>> > My question: What is the best way to handle this, and is there a way
>> > for
>> > me
>> > to just pass the user DN (or SID, SAMAccountName, etc), and have AD
>> > determine
>> > if it that user is allowed to access that object.
>> >
>> > I've found code that should be able to get the user's security token,
>> > and
>> > parse the SIDs it contains. I'm assuming I could then take that list
>> > of
>> > SIDs, and compare it to the list of users/groups that have Write
>> > Members
>> > set
>> > to allow on the group in question. This seems ugly/wrong. There are
>> > too
>> > many cases where this falls short (i.e. the user is a member of a group
>> > that
>> > doesn't have the Write Members permission, but it does have the Write
>> > All
>> > Properties permission. It also doesn't effectively check for deny
>> > entries.)
>> > It feels like there should be a way for me to simply [programatically]
>> > ask
>> > AD
>> > if user X has access to update the "member" attribute on a given group.
>> >
>> > I am a Systems Engineer and not (yet) a programmer, so a little more
>> > verbose
>> > answer is very much appreciated.
>> >
>> > Thanks!
>>
>>
date: Wed, 9 Apr 2008 20:27:38 -0500
author: Joe Kaplan
|
|
