 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Security / January 2008Determine 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=en&q=c%23+IdentityReference+group [2] http://msdn2.microsoft.com/en-us/library/system.security.principal.windowsidenti ty.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.  SignatureJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- > Hi All, > [quoted text clipped - 33 lines] > [2] > http://msdn2.microsoft.com/en-us/library/system.security.principal.windowsidenti ty.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...@removethis.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 [quoted text clipped - 17 lines] > Joe Kaplan-MS MVP Directory Services Programming > Co-author of "The .NET Developer's Guide to Directory Services Programming"http://www.directoryprogramming.net [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. SignatureJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- 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...@removethis.accenture.com> wrote: > I think there is a p/invoke you can use to get the type of the SID, but > why [quoted text clipped - 24 lines] > > news:b22f5d3a-fae9-49e8-be84-c78af6b84873@1g2000hsl.googlegroups.com... [SNIP] Hi Jeff, Just to make sure I'm understanding you correctly: You need to tell whether a sid is a user account or group, correct? If so, I had the same problem and there are two solutions (that I could find). Get the Win32Security.dll You can then easily determine the type of sid but, you're using interop to do this. My other solution, which I went with, is to return all user accounts from the domain with an ldap query and then check the account in question against this list. The drawback is the first time the app is run, it takes about 10 seconds to populate the list. But in our case 10 to 15 seconds is trivial compared to the time it takes to perform the task in question. SignatureDan > Hi All, > [quoted text clipped - 33 lines] > [2] > http://msdn2.microsoft.com/en-us/library/system.security.principal.windowsidenti ty.aspx How about SecurityIdentifier.IsAccountSid() ?? ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) > Hi All, > [quoted text clipped - 31 lines] > http://msdn2.microsoft.com/en-us/library/system.security.principal.win > dowsidentity.aspx Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.