Required permissions to read ntSecurityDescriptor
Magnusb
objects (trying to find all Exchange Distribution groups which a named
user has full control or write member).
This works fine as long as I am running with an account with
administrator rights. However the problem is that I need to do this with
an account with more limited priviliges. When I run with another account
ntSecurityDescriptor is null.
I only need to do this for a specific ou (and children). I have tried to
set the allow read/write ntSecurityDescriptor permission using ADSI edit
but still can't read ntSecurityDescriptor. Any ideas what to do?
Joe Kaplan
parts of the SD you want to read. By default, admin permission is required
to read the SACL part of the SD while the rest is "general". Thus, if you
search with the control that allows you specify this and just ask for owner,
group and DACL you should have no problems.
ADSI does this for you by default in most cases, but lower level APIs do not
and you must account for this or will get the results you are seeing. In
some cases, you must be explicit about this in ADSI as well.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Magnusb" <mag...@sbbs.se> wrote in message
news:MPG.259310725...@msnews.microsoft.com...
Magnusb
joseph....@removethis.accenture.com says...
> You need to make sure you use the proper search control that specifies which
> parts of the SD you want to read. By default, admin permission is required
> to read the SACL part of the SD while the rest is "general"
Thank you. I already found how to do it. Finally managed to do a good
google search and actually found something you had written about adding
SecurityDescriptorFlagControl. I am using SDS.P.
Do you have any advice about speeding up the operation? I am trying to
find if a specified user has full access / write member rights to
Distribution groups. Seems that the part to check the access rights is
pretty slow compared to the time it takes to retrieve the groups. I am
searching 7k groups so there is a need to choose the fastest method.
What I am doing is somehting like:
1) Use SetSecurityDescriptorBinaryForm with ntSecurityDescriptor
2) Use GetAccessRules of ActiveDirectorySecurity class to ge a list of
access rules
3) Filter Access rules on IdentityReference is same as SID for user
4) Evaule ActiveDirectoryRights for each access rule found in 3)
Not sure which part of this operation is the slowest. need to test this.
But first try my test code in production environment and see how it
runs. Maybe fast enough anyway (doing the same operation using Exchange
Shell and Powershell cmdlet take almost a minute that is why I am
looking for using AD directly).
Thank you
Joe Kaplan
that will return an array of strings that contains the ldapDisplayName of
each attribute on the matching object that the current "bound" user has
rights to modify. This is BY FAR the fastest and most reliable way to
determine if a user can modify something.
The trick is that it works in the context of the authenticated user, so if
you cannot bind as the user in question, you can't easily leverage this.
I think the other "preferred" way to do this is to invoke one of the
AccessCheck APIs (probably AuthZAccessCheck) to request a specific operation
against a specific object with a specific security context. Reading the DACL
directly is really complicated as you need to know ALL the SIDs in the
user's token and you need to take into account deny vs. allow and general
vs. specific attribute permissions (vs. control access right permission
sets). It is very ugly code.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Magnusb" <mag...@sbbs.se> wrote in message
news:MPG.2593396c7...@msnews.microsoft.com...
Magnusb
joseph....@removethis.accenture.com says...
> If you do a search and request the "allowedAttributesEffective" attribute,
> that will return an array of strings that contains the ldapDisplayName of
> each attribute on the matching object that the current "bound" user has
> rights to modify. This is BY FAR the fastest and most reliable way to
> determine if a user can modify something.
>
> The trick is that it works in the context of the authenticated user, so if
> you cannot bind as the user in question, you can't easily leverage this.
Can't use the authenticade user. But I noticed performance was not that
bad when running outside the IDE. When I run within VS every
SetSecurityDescriptorBinaryForm took 3-4 ms each (doesn't seem much but
when you have to do that operation for 7k objects it adds up). The time
to SetSecurityDescriptorBinaryForm took about twice as much time as it
took to read 500 groups from AD. But outside IDE it was very fast (down
to ~10 ms for 500 objects).
Will try the code tomorrow and see how it will run in production
environment with 7k groups (and 50k+ users in AD). Will most certainly
be many magnitudes faster than doing this in Powershell.
I agree that reading the DACL is pretty ugly but in this case not that
bad. Only need to check for full access and "write member" permission
(took some time until I realized how to get the extended properties).
BTW, don't you just love the SDS.P documentation. The explanation for
SecurityDescriptorFlagControl:
"The SecurityDescriptorFlagControl class is used to pass flags to the
server to control various security descriptor behaviors."
Thank you. That really says everything you need to know :-). Some MS
documentation is good. Much are not very good, but SDS.P is really,
really bad :-).
Joe Kaplan
and that's saying a lot! I've mentioned this to the team. Perhaps I'll
mention it again. I don't expect any effort by them to address it though.
Good luck with the project!
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
>
Magnusb
joseph....@removethis.accenture.com says...
> It is the worst API documentation I've seen in the entire .NET Framework SDK
> and that's saying a lot! I've mentioned this to the team. Perhaps I'll
> mention it again. I don't expect any effort by them to address it though.
Hehe yes I agree. Maybe you should write a new book focusing on SDS.P
:-).
> Good luck with the project!
Thank you.