Determine if IdentityReference is a Security Group

Hi All,

I've been trudging through old posts, but can't seem to find an
answer. This is the 'Effective Permissions' problem. I've seen a lot
of 'You Can't" and "Do it Using PInvoke/Windows API". I'd like to stay
with a C# solution. Google is only returning two pages. The pages
returned are more of the question, "Is the user a member of a
group?" [1].

From the files system object (directory or file), I have a collection
of AuthorizationRules. I need place the rules (some hand waiving) into
bins to enforce Windows Security business logic (order of Allow/Deny
and User/Group matters):

DenyUser
DenyGroups
AllowUser
AllowGroups

Allow and Deny are easily obtained from IdentityReference. The Sid is
easily obtained also. However, given an IdentityReference (or SID),
how do I determine if it is a Security Group? In a nushell, I want:

IsSecurityGroup( IdentityReference id ) or
IsSecurityGroup( SecurityIdentifier sid )

WindowsIdentity Class does not offer the function [2]. Given a user,
WindowsIdentity will give me a list of the user's groups. But I do not
need this information.

Thanks,
Jeff
Jeffrey Walton

[1] http://groups.google.com/groups?hl=e...eference+group
[2] http://msdn2.microsoft.com/en-us/lib...sidentity.aspx

I think there is a p/invoke you can use to get the type of the SID, but why
would you need to do this? Normally, when this type of comparison is being
made, you create a "token" for the user that contains their SID, the
expanded list of group SIDs and all of the other built-in SIDs (like
authenticated users and such) and compare those against the SIDs in the ACL.
Depending on what matches, the allow or deny is calculated. You don't
actually need to know what the type of the SID is to perform the match.

Also note that OS permissions are more complex than just the ACEs in the
DACL, as OS level privileges are also taken into account by the OS. For
example, backup operators can read files that they may not actually be
granted access to read by the DACL. I don't know whether you need to
consider that or not, but that is an important part of the OS authorization
logic. That is one of the primary reasons why people (like me) generally
recommend that you don't try to implement this logic yourself.

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
--
"Jeffrey Walton" <noloader (AT) gmail (DOT) com> wrote

Hi All,

I've been trudging through old posts, but can't seem to find an
answer. This is the 'Effective Permissions' problem. I've seen a lot
of 'You Can't" and "Do it Using PInvoke/Windows API". I'd like to stay
with a C# solution. Google is only returning two pages. The pages
returned are more of the question, "Is the user a member of a
group?" [1].

From the files system object (directory or file), I have a collection
of AuthorizationRules. I need place the rules (some hand waiving) into
bins to enforce Windows Security business logic (order of Allow/Deny
and User/Group matters):

DenyUser
DenyGroups
AllowUser
AllowGroups

Allow and Deny are easily obtained from IdentityReference. The Sid is
easily obtained also. However, given an IdentityReference (or SID),
how do I determine if it is a Security Group? In a nushell, I want:

IsSecurityGroup( IdentityReference id ) or
IsSecurityGroup( SecurityIdentifier sid )

WindowsIdentity Class does not offer the function [2]. Given a user,
WindowsIdentity will give me a list of the user's groups. But I do not
need this information.

Thanks,
Jeff
Jeffrey Walton

[1] http://groups.google.com/groups?hl=e...eference+group
[2]
http://msdn2.microsoft.com/en-us/lib...sidentity.aspx

Hi Joe,

Thanks for the reply.

against the SIDs in the ACL. Depending on what matches,
the allow or deny is calculated.
Correct. But, a User Allow is placed before a Group Deny. For example,

suppose I have a DACL which allows user John Doe, but denies John Doe
Group. John would have access because the user allow is placed before
the group deny. Hence the need to differentiates between the ACEs.

backup operators can read files that they may not
actually be granted access to read by the DACL.
I'm going to punt on this in the program.

What I need to do is procees a lot of data over the network. So I
want to use the above as a sanity check. This way, the program does
not get 10 minutes in and catch an exception which could have been
determined early. My thinking is, why waste everyone's time with a
basic mistake? I don't like it when I use a program and it happens to
me.

Jeff

On Dec 27, 11:58*am, "Joe Kaplan"
<joseph.e.kap... (AT) removethis (DOT) accenture.com> wrote:

I think there is a p/invoke you can use to get the type of the SID, but why
would you need to do this? *Normally, when this type of comparison is being
made, you create a "token" for the user that contains their SID, the
expanded list of group SIDs and all of the other built-in SIDs (like
authenticated users and such) and compare those against the SIDs in the ACL.
Depending on what matches, the allow or deny is calculated. *You don't
actually need to know what the type of the SID is to perform the match.

Also note that OS permissions are more complex than just the ACEs in the
DACL, as OS level privileges are also taken into account by the OS. *For
example, backup operators can read files that they may not actually be
granted access to read by the DACL. *I don't know whether you need to
consider that or not, but that is an important part of the OS authorization
logic. *That is one of the primary reasons why people (like me) generally
recommend that you don't try to implement this logic yourself. *

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
--"Jeffrey Walton" <noloa... (AT) gmail (DOT) com> wrote in message

news:b22f5d3a-fae9-49e8-be84-c78af6b84873 (AT) 1g2000hsl (DOT) googlegroups.com...

[SNIP]

You should be processing based on the SID value, not the trustee name. The
user John Doe and the group John Doe will have different SIDs, so that won't
be a problem. It is not actually possible for you to have duplicate
sAMAccountName values for a security principal in the same domain though, so
the only way you could duplicate them would be via the same account in
different domains. If you use the fully qualified NT account name
(domain\user), you should not have collisions based on account names either.

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
--
"Jeffrey Walton" <noloader (AT) gmail (DOT) com> wrote

Hi Joe,

Thanks for the reply.

against the SIDs in the ACL. Depending on what matches,
the allow or deny is calculated.
Correct. But, a User Allow is placed before a Group Deny. For example,

suppose I have a DACL which allows user John Doe, but denies John Doe
Group. John would have access because the user allow is placed before
the group deny. Hence the need to differentiates between the ACEs.

backup operators can read files that they may not
actually be granted access to read by the DACL.
I'm going to punt on this in the program.

What I need to do is procees a lot of data over the network. So I
want to use the above as a sanity check. This way, the program does
not get 10 minutes in and catch an exception which could have been
determined early. My thinking is, why waste everyone's time with a
basic mistake? I don't like it when I use a program and it happens to
me.

Jeff

On Dec 27, 11:58 am, "Joe Kaplan"
<joseph.e.kap... (AT) removethis (DOT) accenture.com> wrote:

I think there is a p/invoke you can use to get the type of the SID, but
why
would you need to do this? Normally, when this type of comparison is being
made, you create a "token" for the user that contains their SID, the
expanded list of group SIDs and all of the other built-in SIDs (like
authenticated users and such) and compare those against the SIDs in the
ACL.
Depending on what matches, the allow or deny is calculated. You don't
actually need to know what the type of the SID is to perform the match.

Also note that OS permissions are more complex than just the ACEs in the
DACL, as OS level privileges are also taken into account by the OS. For
example, backup operators can read files that they may not actually be
granted access to read by the DACL. I don't know whether you need to
consider that or not, but that is an important part of the OS
authorization
logic. That is one of the primary reasons why people (like me) generally
recommend that you don't try to implement this logic yourself.

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
--"Jeffrey Walton" <noloa... (AT) gmail (DOT) com> wrote in message

news:b22f5d3a-fae9-49e8-be84-c78af6b84873 (AT) 1g2000hsl (DOT) googlegroups.com...

[SNIP]