| Groups | Blog | Home |
dotnet security : .net 2.0: exception getting DirectorySecurity on a particular directory
them, I get a System.ArgumentException stating "The binary form of an ACE object is invalid. Parameter name: binaryForm" All I'm doing is the following: DirectorySecurity sec = new DirectorySecurity(path, AccessControlSections.Access); If I look at the directory in Windows Explorer, there are some SIDs which do not translate to named accounts, but I am still able to view it fine. Is there some way I can get the SDDL or binary representation within .net 2.0, or do I have to resort to native methods?
SIDs do not appear to be mapped to names during the ACE binary form
validation, so I suspect that this isn't what is causing your particular problem. It's likely that it may be necessary for your exact ACE entries to be examined to determine the cause, so you might want to consider reporting this as a bug at http://lab.msdn.microsoft.com/productfeedback/. In the meantime, it sounds like using p/invoke to the underlying APIs might be your safest bet... [quoted text, click to view] "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message news:uiNuWk%23MGHA.1028@TK2MSFTNGP11.phx.gbl... > I'm trying to enumerate the acls on various directories, and on a couple > of them, I get a System.ArgumentException stating > "The binary form of an ACE object is invalid. > Parameter name: binaryForm" > > All I'm doing is the following: > DirectorySecurity sec = new DirectorySecurity(path, > AccessControlSections.Access); > > If I look at the directory in Windows Explorer, there are some SIDs which > do not translate to named accounts, but I am still able to view it fine. > Is there some way I can get the SDDL or binary representation within .net > 2.0, or do I have to resort to native methods? > >
I have a .net 1.1 library I got from GotDotNet which p/invokes into the
Win32 API. On the directories I get that exception in .net 2.0, the 1.1 library complains that the SID's length is 36, when it is supposed to be 24. So it appears there is something wrong with the ACLs on these directories. [quoted text, click to view] "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:uv5pdJXNGHA.3408@TK2MSFTNGP14.phx.gbl... > SIDs do not appear to be mapped to names during the ACE binary form > validation, so I suspect that this isn't what is causing your particular > problem. It's likely that it may be necessary for your exact ACE entries > to be examined to determine the cause, so you might want to consider > reporting this as a bug at http://lab.msdn.microsoft.com/productfeedback/. > In the meantime, it sounds like using p/invoke to the underlying APIs > might be your safest bet... > > > > "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message > news:uiNuWk%23MGHA.1028@TK2MSFTNGP11.phx.gbl... >> I'm trying to enumerate the acls on various directories, and on a couple >> of them, I get a System.ArgumentException stating >> "The binary form of an ACE object is invalid. >> Parameter name: binaryForm" >> >> All I'm doing is the following: >> DirectorySecurity sec = new DirectorySecurity(path, >> AccessControlSections.Access); >> >> If I look at the directory in Windows Explorer, there are some SIDs which >> do not translate to named accounts, but I am still able to view it fine. >> Is there some way I can get the SDDL or binary representation within .net >> 2.0, or do I have to resort to native methods? >> >> > >
SIDs should be even multiples of 4 bytes, so 36 should be ok. That would
be a SID with 7 sub authorities, which is a lot, but still a legal value. I thought 15 was the max. According to WinNT.h: #define SID_MAX_SUB_AUTHORITIES (15) Perhaps it is a bug in the library? Joe K. [quoted text, click to view] "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message news:eJ6sT2UPGHA.1028@TK2MSFTNGP11.phx.gbl... >I have a .net 1.1 library I got from GotDotNet which p/invokes into the >Win32 API. On the directories I get that exception in .net 2.0, the 1.1 >library complains that the SID's length is 36, when it is supposed to be >24. So it appears there is something wrong with the ACLs on these >directories. > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:uv5pdJXNGHA.3408@TK2MSFTNGP14.phx.gbl... >> SIDs do not appear to be mapped to names during the ACE binary form >> validation, so I suspect that this isn't what is causing your particular >> problem. It's likely that it may be necessary for your exact ACE entries >> to be examined to determine the cause, so you might want to consider >> reporting this as a bug at >> http://lab.msdn.microsoft.com/productfeedback/. In the meantime, it >> sounds like using p/invoke to the underlying APIs might be your safest >> bet... >> >> >> >> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >> news:uiNuWk%23MGHA.1028@TK2MSFTNGP11.phx.gbl... >>> I'm trying to enumerate the acls on various directories, and on a couple >>> of them, I get a System.ArgumentException stating >>> "The binary form of an ACE object is invalid. >>> Parameter name: binaryForm" >>> >>> All I'm doing is the following: >>> DirectorySecurity sec = new DirectorySecurity(path, >>> AccessControlSections.Access); >>> >>> If I look at the directory in Windows Explorer, there are some SIDs >>> which do not translate to named accounts, but I am still able to view it >>> fine. Is there some way I can get the SDDL or binary representation >>> within .net 2.0, or do I have to resort to native methods? >>> >>> >> >> > >
This I'm not sure about. I thought it was in reference to a SID by itself,
but it looks like the SID is in another structure here. If you can, maybe you can get an SDDL dump of the SD for the objects in question and send them to PSS. It seems uncool that the .NET 2.0 libraries would crash on an SD that you actually have, even if it is goofed up somehow. There is probably some cool tool to get the SDDL of an SD easily, but I'm not sure what it is. Joe K. [quoted text, click to view] "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message news:OzDFnhXPGHA.1760@TK2MSFTNGP10.phx.gbl... > Here are the definitions for the structs in the library... > [StructLayout(LayoutKind.Sequential)] > > public struct ACE_HEADER > > { > > public static readonly int SizeOf = Marshal.SizeOf(typeof(ACE_HEADER)); > > public AceType AceType; > > public AceFlags AceFlags; > > public WORD AceSize; > > } > > > > [StructLayout(LayoutKind.Sequential)] > > public struct ACCESS_ALLOWED_ACE > > { > > public static readonly int SizeOf = > Marshal.SizeOf(typeof(ACCESS_ALLOWED_ACE)); > > public static readonly int SidOffset = > Marshal.OffsetOf(typeof(ACCESS_ALLOWED_ACE), "SidStart").ToInt32(); > > public ACE_HEADER Header; > > public ACCESS_MASK Mask; > > public DWORD SidStart; > > } > > So I'm guessing it's expecting the AceSize to match the offset of the > SidStart field. Could be a bug in the library.... > > > "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message > news:e4Tm7bXPGHA.516@TK2MSFTNGP15.phx.gbl... >> Maybe, but then why would the .net 2.0 library from MS crash on the same >> directories? Unless they both have the same bug... >> The code in the 1.1 library that fails looks like this: >> >> /// <summary> >> >> /// Sanety check of the state of our members. >> >> /// We don't want to make this method Debug-only, because we are dealing >> with >> >> /// security objects! >> >> /// </summary> >> >> protected unsafe void CheckInvariant() >> >> { >> >> int headerSize = _header.AceSize; >> >> int compSize = OffsetOfSid() + _sid.Size; >> >> if (headerSize != compSize) >> >> { >> >> string msg = string.Format( >> >> "Invariant of Ace is not verified (size is {0} instead of {1})", >> >> headerSize, compSize); >> >> throw new InvalidOperationException(msg); >> >> } >> >> if (_sid == null) >> >> throw new InvalidOperationException( >> >> "Invariant of Ace is not verified: sid member is null"); >> >> } >> >> The _header field is of type ACE_HEADER. OffsetOfSid() returns >> ACCESS_ALLOWED_ACE.SidOffset. I don't really know the Win32 api for >> acls, but I think those are native structs. >> Perhaps the size from the header does not match the actual size of the >> SID. Either way it appears the folder's ACLs are borked somehow... >> >> "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> >> wrote in message news:eJS%23WMXPGHA.344@TK2MSFTNGP11.phx.gbl... >>> SIDs should be even multiples of 4 bytes, so 36 should be ok. That >>> would be a SID with 7 sub authorities, which is a lot, but still a legal >>> value. I thought 15 was the max. According to WinNT.h: >>> >>> #define SID_MAX_SUB_AUTHORITIES (15) >>> >>> Perhaps it is a bug in the library? >>> >>> Joe K. >>> >>> >>> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >>> news:eJ6sT2UPGHA.1028@TK2MSFTNGP11.phx.gbl... >>>>I have a .net 1.1 library I got from GotDotNet which p/invokes into the >>>>Win32 API. On the directories I get that exception in .net 2.0, the 1.1 >>>>library complains that the SID's length is 36, when it is supposed to be >>>>24. So it appears there is something wrong with the ACLs on these >>>>directories. >>>> >>>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in >>>> message news:uv5pdJXNGHA.3408@TK2MSFTNGP14.phx.gbl... >>>>> SIDs do not appear to be mapped to names during the ACE binary form >>>>> validation, so I suspect that this isn't what is causing your >>>>> particular problem. It's likely that it may be necessary for your >>>>> exact ACE entries to be examined to determine the cause, so you might >>>>> want to consider reporting this as a bug at >>>>> http://lab.msdn.microsoft.com/productfeedback/. In the meantime, it >>>>> sounds like using p/invoke to the underlying APIs might be your safest >>>>> bet... >>>>> >>>>> >>>>> >>>>> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >>>>> news:uiNuWk%23MGHA.1028@TK2MSFTNGP11.phx.gbl... >>>>>> I'm trying to enumerate the acls on various directories, and on a >>>>>> couple of them, I get a System.ArgumentException stating >>>>>> "The binary form of an ACE object is invalid. >>>>>> Parameter name: binaryForm" >>>>>> >>>>>> All I'm doing is the following: >>>>>> DirectorySecurity sec = new DirectorySecurity(path, >>>>>> AccessControlSections.Access); >>>>>> >>>>>> If I look at the directory in Windows Explorer, there are some SIDs >>>>>> which do not translate to named accounts, but I am still able to view >>>>>> it fine. Is there some way I can get the SDDL or binary >>>>>> representation within .net 2.0, or do I have to resort to native >>>>>> methods? >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
Maybe, but then why would the .net 2.0 library from MS crash on the same
directories? Unless they both have the same bug... The code in the 1.1 library that fails looks like this: /// <summary> /// Sanety check of the state of our members. /// We don't want to make this method Debug-only, because we are dealing with /// security objects! /// </summary> protected unsafe void CheckInvariant() { int headerSize = _header.AceSize; int compSize = OffsetOfSid() + _sid.Size; if (headerSize != compSize) { string msg = string.Format( "Invariant of Ace is not verified (size is {0} instead of {1})", headerSize, compSize); throw new InvalidOperationException(msg); } if (_sid == null) throw new InvalidOperationException( "Invariant of Ace is not verified: sid member is null"); } The _header field is of type ACE_HEADER. OffsetOfSid() returns ACCESS_ALLOWED_ACE.SidOffset. I don't really know the Win32 api for acls, but I think those are native structs. Perhaps the size from the header does not match the actual size of the SID. Either way it appears the folder's ACLs are borked somehow... [quoted text, click to view] "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote in message news:eJS%23WMXPGHA.344@TK2MSFTNGP11.phx.gbl... > SIDs should be even multiples of 4 bytes, so 36 should be ok. That would > be a SID with 7 sub authorities, which is a lot, but still a legal value. > I thought 15 was the max. According to WinNT.h: > > #define SID_MAX_SUB_AUTHORITIES (15) > > Perhaps it is a bug in the library? > > Joe K. > > > "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message > news:eJ6sT2UPGHA.1028@TK2MSFTNGP11.phx.gbl... >>I have a .net 1.1 library I got from GotDotNet which p/invokes into the >>Win32 API. On the directories I get that exception in .net 2.0, the 1.1 >>library complains that the SID's length is 36, when it is supposed to be >>24. So it appears there is something wrong with the ACLs on these >>directories. >> >> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message >> news:uv5pdJXNGHA.3408@TK2MSFTNGP14.phx.gbl... >>> SIDs do not appear to be mapped to names during the ACE binary form >>> validation, so I suspect that this isn't what is causing your particular >>> problem. It's likely that it may be necessary for your exact ACE >>> entries to be examined to determine the cause, so you might want to >>> consider reporting this as a bug at >>> http://lab.msdn.microsoft.com/productfeedback/. In the meantime, it >>> sounds like using p/invoke to the underlying APIs might be your safest >>> bet... >>> >>> >>> >>> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >>> news:uiNuWk%23MGHA.1028@TK2MSFTNGP11.phx.gbl... >>>> I'm trying to enumerate the acls on various directories, and on a >>>> couple of them, I get a System.ArgumentException stating >>>> "The binary form of an ACE object is invalid. >>>> Parameter name: binaryForm" >>>> >>>> All I'm doing is the following: >>>> DirectorySecurity sec = new DirectorySecurity(path, >>>> AccessControlSections.Access); >>>> >>>> If I look at the directory in Windows Explorer, there are some SIDs >>>> which do not translate to named accounts, but I am still able to view >>>> it fine. Is there some way I can get the SDDL or binary representation >>>> within .net 2.0, or do I have to resort to native methods? >>>> >>>> >>> >>> >> >> > >
Here are the definitions for the structs in the library...
[StructLayout(LayoutKind.Sequential)] public struct ACE_HEADER { public static readonly int SizeOf = Marshal.SizeOf(typeof(ACE_HEADER)); public AceType AceType; public AceFlags AceFlags; public WORD AceSize; } [StructLayout(LayoutKind.Sequential)] public struct ACCESS_ALLOWED_ACE { public static readonly int SizeOf = Marshal.SizeOf(typeof(ACCESS_ALLOWED_ACE)); public static readonly int SidOffset = Marshal.OffsetOf(typeof(ACCESS_ALLOWED_ACE), "SidStart").ToInt32(); public ACE_HEADER Header; public ACCESS_MASK Mask; public DWORD SidStart; } So I'm guessing it's expecting the AceSize to match the offset of the SidStart field. Could be a bug in the library.... [quoted text, click to view] "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message news:e4Tm7bXPGHA.516@TK2MSFTNGP15.phx.gbl... > Maybe, but then why would the .net 2.0 library from MS crash on the same > directories? Unless they both have the same bug... > The code in the 1.1 library that fails looks like this: > > /// <summary> > > /// Sanety check of the state of our members. > > /// We don't want to make this method Debug-only, because we are dealing > with > > /// security objects! > > /// </summary> > > protected unsafe void CheckInvariant() > > { > > int headerSize = _header.AceSize; > > int compSize = OffsetOfSid() + _sid.Size; > > if (headerSize != compSize) > > { > > string msg = string.Format( > > "Invariant of Ace is not verified (size is {0} instead of {1})", > > headerSize, compSize); > > throw new InvalidOperationException(msg); > > } > > if (_sid == null) > > throw new InvalidOperationException( > > "Invariant of Ace is not verified: sid member is null"); > > } > > The _header field is of type ACE_HEADER. OffsetOfSid() returns > ACCESS_ALLOWED_ACE.SidOffset. I don't really know the Win32 api for acls, > but I think those are native structs. > Perhaps the size from the header does not match the actual size of the > SID. Either way it appears the folder's ACLs are borked somehow... > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote > in message news:eJS%23WMXPGHA.344@TK2MSFTNGP11.phx.gbl... >> SIDs should be even multiples of 4 bytes, so 36 should be ok. That >> would be a SID with 7 sub authorities, which is a lot, but still a legal >> value. I thought 15 was the max. According to WinNT.h: >> >> #define SID_MAX_SUB_AUTHORITIES (15) >> >> Perhaps it is a bug in the library? >> >> Joe K. >> >> >> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >> news:eJ6sT2UPGHA.1028@TK2MSFTNGP11.phx.gbl... >>>I have a .net 1.1 library I got from GotDotNet which p/invokes into the >>>Win32 API. On the directories I get that exception in .net 2.0, the 1.1 >>>library complains that the SID's length is 36, when it is supposed to be >>>24. So it appears there is something wrong with the ACLs on these >>>directories. >>> >>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in >>> message news:uv5pdJXNGHA.3408@TK2MSFTNGP14.phx.gbl... >>>> SIDs do not appear to be mapped to names during the ACE binary form >>>> validation, so I suspect that this isn't what is causing your >>>> particular problem. It's likely that it may be necessary for your >>>> exact ACE entries to be examined to determine the cause, so you might >>>> want to consider reporting this as a bug at >>>> http://lab.msdn.microsoft.com/productfeedback/. In the meantime, it >>>> sounds like using p/invoke to the underlying APIs might be your safest >>>> bet... >>>> >>>> >>>> >>>> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >>>> news:uiNuWk%23MGHA.1028@TK2MSFTNGP11.phx.gbl... >>>>> I'm trying to enumerate the acls on various directories, and on a >>>>> couple of them, I get a System.ArgumentException stating >>>>> "The binary form of an ACE object is invalid. >>>>> Parameter name: binaryForm" >>>>> >>>>> All I'm doing is the following: >>>>> DirectorySecurity sec = new DirectorySecurity(path, >>>>> AccessControlSections.Access); >>>>> >>>>> If I look at the directory in Windows Explorer, there are some SIDs >>>>> which do not translate to named accounts, but I am still able to view >>>>> it fine. Is there some way I can get the SDDL or binary representation >>>>> within .net 2.0, or do I have to resort to native methods? >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
I can use cacls /s to get the SDDL string, but that doesn't seem to bother
the .net 2.0 classes. I'm trying to figure out if I can get the binary form since that seems to be what is tripping things up. [quoted text, click to view] "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote in message news:udBY8lXPGHA.1696@TK2MSFTNGP14.phx.gbl... > This I'm not sure about. I thought it was in reference to a SID by > itself, but it looks like the SID is in another structure here. > > If you can, maybe you can get an SDDL dump of the SD for the objects in > question and send them to PSS. It seems uncool that the .NET 2.0 > libraries would crash on an SD that you actually have, even if it is > goofed up somehow. > > There is probably some cool tool to get the SDDL of an SD easily, but I'm > not sure what it is. > > Joe K. > > "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message > news:OzDFnhXPGHA.1760@TK2MSFTNGP10.phx.gbl... >> Here are the definitions for the structs in the library... >> [StructLayout(LayoutKind.Sequential)] >> >> public struct ACE_HEADER >> >> { >> >> public static readonly int SizeOf = Marshal.SizeOf(typeof(ACE_HEADER)); >> >> public AceType AceType; >> >> public AceFlags AceFlags; >> >> public WORD AceSize; >> >> } >> >> >> >> [StructLayout(LayoutKind.Sequential)] >> >> public struct ACCESS_ALLOWED_ACE >> >> { >> >> public static readonly int SizeOf = >> Marshal.SizeOf(typeof(ACCESS_ALLOWED_ACE)); >> >> public static readonly int SidOffset = >> Marshal.OffsetOf(typeof(ACCESS_ALLOWED_ACE), "SidStart").ToInt32(); >> >> public ACE_HEADER Header; >> >> public ACCESS_MASK Mask; >> >> public DWORD SidStart; >> >> } >> >> So I'm guessing it's expecting the AceSize to match the offset of the >> SidStart field. Could be a bug in the library.... >> >> >> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >> news:e4Tm7bXPGHA.516@TK2MSFTNGP15.phx.gbl... >>> Maybe, but then why would the .net 2.0 library from MS crash on the same >>> directories? Unless they both have the same bug... >>> The code in the 1.1 library that fails looks like this: >>> >>> /// <summary> >>> >>> /// Sanety check of the state of our members. >>> >>> /// We don't want to make this method Debug-only, because we are dealing >>> with >>> >>> /// security objects! >>> >>> /// </summary> >>> >>> protected unsafe void CheckInvariant() >>> >>> { >>> >>> int headerSize = _header.AceSize; >>> >>> int compSize = OffsetOfSid() + _sid.Size; >>> >>> if (headerSize != compSize) >>> >>> { >>> >>> string msg = string.Format( >>> >>> "Invariant of Ace is not verified (size is {0} instead of {1})", >>> >>> headerSize, compSize); >>> >>> throw new InvalidOperationException(msg); >>> >>> } >>> >>> if (_sid == null) >>> >>> throw new InvalidOperationException( >>> >>> "Invariant of Ace is not verified: sid member is null"); >>> >>> } >>> >>> The _header field is of type ACE_HEADER. OffsetOfSid() returns >>> ACCESS_ALLOWED_ACE.SidOffset. I don't really know the Win32 api for >>> acls, but I think those are native structs. >>> Perhaps the size from the header does not match the actual size of the >>> SID. Either way it appears the folder's ACLs are borked somehow... >>> >>> "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> >>> wrote in message news:eJS%23WMXPGHA.344@TK2MSFTNGP11.phx.gbl... >>>> SIDs should be even multiples of 4 bytes, so 36 should be ok. That >>>> would be a SID with 7 sub authorities, which is a lot, but still a >>>> legal value. I thought 15 was the max. According to WinNT.h: >>>> >>>> #define SID_MAX_SUB_AUTHORITIES (15) >>>> >>>> Perhaps it is a bug in the library? >>>> >>>> Joe K. >>>> >>>> >>>> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >>>> news:eJ6sT2UPGHA.1028@TK2MSFTNGP11.phx.gbl... >>>>>I have a .net 1.1 library I got from GotDotNet which p/invokes into the >>>>>Win32 API. On the directories I get that exception in .net 2.0, the >>>>>1.1 library complains that the SID's length is 36, when it is supposed >>>>>to be 24. So it appears there is something wrong with the ACLs on these >>>>>directories. >>>>> >>>>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in >>>>> message news:uv5pdJXNGHA.3408@TK2MSFTNGP14.phx.gbl... >>>>>> SIDs do not appear to be mapped to names during the ACE binary form >>>>>> validation, so I suspect that this isn't what is causing your >>>>>> particular problem. It's likely that it may be necessary for your >>>>>> exact ACE entries to be examined to determine the cause, so you might >>>>>> want to consider reporting this as a bug at >>>>>> http://lab.msdn.microsoft.com/productfeedback/. In the meantime, it >>>>>> sounds like using p/invoke to the underlying APIs might be your >>>>>> safest bet... >>>>>> >>>>>> >>>>>> >>>>>> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >>>>>> news:uiNuWk%23MGHA.1028@TK2MSFTNGP11.phx.gbl... >>>>>>> I'm trying to enumerate the acls on various directories, and on a >>>>>>> couple of them, I get a System.ArgumentException stating >>>>>>> "The binary form of an ACE object is invalid. >>>>>>> Parameter name: binaryForm" >>>>>>> >>>>>>> All I'm doing is the following: >>>>>>> DirectorySecurity sec = new DirectorySecurity(path, >>>>>>> AccessControlSections.Access); >>>>>>> >>>>>>> If I look at the directory in Windows Explorer, there are some SIDs >>>>>>> which do not translate to named accounts, but I am still able to >>>>>>> view it fine. Is there some way I can get the SDDL or binary >>>>>>> representation within .net 2.0, or do I have to resort to native >>>>>>> methods? >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
If you use .NET to convert the SDDL back to binary, does it crash and are
the bytes the same? Maybe there is a wierd canonicalization issue with the binary format? Joe K. [quoted text, click to view] "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message news:OzcYQzXPGHA.1088@tk2msftngp13.phx.gbl... >I can use cacls /s to get the SDDL string, but that doesn't seem to bother >the .net 2.0 classes. I'm trying to figure out if I can get the binary >form since that seems to be what is tripping things up. >
There are a bunch of conversion functions like
ConvertSecurityDescriptorToStringSecurityDescriptor and ConvertStringSecurityDescriptorToSecurityDescriptor. They have many friends as well. :) You could try doing P/Invoke on those. Joe K. [quoted text, click to view] "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message news:%23X0CZIiPGHA.1360@TK2MSFTNGP10.phx.gbl... >I can't seem to figure out how to access the bytes that get passed to >RawAcl. It's all hidden within some undocumented classes within the class >library as far as I can see. Converting the string to binary form and back >doesn't appear to matter... > > I don't suppose you know how one might do it via the Win32 api? I don't > deal with native much at all... > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote > in message news:O2sLJDaPGHA.3556@TK2MSFTNGP10.phx.gbl... >> If you use .NET to convert the SDDL back to binary, does it crash and are >> the bytes the same? Maybe there is a wierd canonicalization issue with >> the binary format? >> >> Joe K. >> >> "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message >> news:OzcYQzXPGHA.1088@tk2msftngp13.phx.gbl... >>>I can use cacls /s to get the SDDL string, but that doesn't seem to >>>bother the .net 2.0 classes. I'm trying to figure out if I can get the >>>binary form since that seems to be what is tripping things up. >>> >> >> > >
I can't seem to figure out how to access the bytes that get passed to
RawAcl. It's all hidden within some undocumented classes within the class library as far as I can see. Converting the string to binary form and back doesn't appear to matter... I don't suppose you know how one might do it via the Win32 api? I don't deal with native much at all... [quoted text, click to view] "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote in message news:O2sLJDaPGHA.3556@TK2MSFTNGP10.phx.gbl... > If you use .NET to convert the SDDL back to binary, does it crash and are > the bytes the same? Maybe there is a wierd canonicalization issue with > the binary format? > > Joe K. > > "Michael D'Angelo" <nospamnmdange@phoenixworx.org> wrote in message > news:OzcYQzXPGHA.1088@tk2msftngp13.phx.gbl... >>I can use cacls /s to get the SDDL string, but that doesn't seem to bother >>the .net 2.0 classes. I'm trying to figure out if I can get the binary >>form since that seems to be what is tripping things up. >> > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |