joeware - never stop exploring... :)

So I am a little disappointed at the turnout over the responses to the previous “So you think you know AD?” post.

Only M@ was willing to step up and post a public comment and I received about 11 offline responses all saying about the same thing – basically not possible unless some network trickery is involved.

Well folks… it is possible, and not through any special network tricks, it is well within the power of Active Directory to do it. Well Windows Server 2003 and ADAM Active Directory which is why I specifically mentioned a Windows Server 2003 Domain Controller.

In Windows Server 2003 AD (and ADAM) Microsoft exposed a new option value for the LDAP_SERVER_SEARCH_OPTIONS_OID called SERVER_SEARCH_FLAG_PHANTOM_ROOT aka Phantom Root. The description of this option is

Instructs the server to search all NCs that are subordinate to the search base. This will cause the search to be executed over all NCs held on the DC that are subordinate than the search base. This also enables search bases like dc=com, which would cause the server to search all of the NCs that it holds.

So if you submit this control with your query, you can actually use a null search base or any search base you choose say like DC=NET to the LDAP port. This is the same functionality that you get by default when you send the query to the GC Port. It is also the mechanism that you can use to “fake” GC functionality within an ADAM instance with multiple application NCs as mentioned in my book in the ADAM chapter.

So how do you use this? Well AdFind lets you submit the control by using the -PR switch but obviously any program that is using the actual LDAP API instead of say ADSI can also take advantage of it by submitting the proper control.

This is something that can come in useful when doing things in environments which are “filtered”. Or if you want to reduce the number of connections to a given DC in your program. For instance, if the new program I am working on detects that the server it is connected to is a GC and is Windows Server 2003 or better it simply uses the initial connection to it that is already open versus opening another connection to it on the GC port and then managing both connections.

   joe

I was working on a new utility for a little while this evening because I have been thinking about it and my mind needed to get some of it down into c++ code… Anyway, I started thinking of different what if situations and came up with a question that I was curious how people would respond. I have my answer… but what do other people think?

You have a Windows Server 2003 Domain Controller that is a global catalog and you need to query it for all OUs in the entire forest…. The problem is that the reverse proxy only allows you to redirect port 389 to your client and no other domain controller is available to you… How do you query all OU objects in the forest that obviously exist on that GC?

I will let people post comments for a day or so as I am curious as to what people will say… Is it possible? Is it not possible?

   joe

I am slowly working my way through email and ran into a question that I seem to get rather often and the answer actually bothers me.

The email asked:

“Quick question.

What all attributes do I have to give a user permission to in order to set the password when creating an account? I can create the account up to the point where I enter the password. It says insufficient rights to set password, but creates the account in a disabled state. Everything else with the account looks fine.

Thus far, I gave it rights to the 4 pw attributes, useraccountcontrol and pwdlastset. I know i’m missing something just not sure what.”

The answer to the question, what rights do I need to grant to create an enabled user are simply

1. Create Child for the type of object you need to create, in this case user class objects. This permission needs to be applied to the OU (or OU’s) that you want the delegated group to be able to create the user in.

2. Reset password for user class objects.

The thing that bothers me about this is that I shouldn’t need #2. I should be able to just create the object with a password and enabled if I want without having explicit Reset Password… I mean I am creating the object hello and I can set all of the other attributes at creation, why not unicodePwd? What point in creating objects that you can’t actually use?

Done?

Hmmm maybe not… Some of you are probably scratching your head and thinking, the old bird is off his perch… You cannot create an enabled user with just those two permissions configured… Hmmm…. Nope I am not off my perch. I am just used to using a tool that can create users with the minimal necessary permissions – AdMod. It will allow you to create an enabled user with a single ldap_add function call. Those of you who use ADSI or by extension ADSIEDIT or ADUC are not able to do this, there is an add call and then some updates that follow along. That means you have to give out even more permissions. Specifically you need to additionally grant at least:

3. Write Property (WP) to userAccountControl for user class objects

In many instances you may have to grant

4. Read Property (RP) to userAccountControl for user class objects

as well if you have locked down security a little[1]. This is because ADSI seemingly[2] won’t let you set something you cannot read. If you want to expire the user ID so the user immediately has to change their password, you will also need to grant

5. WP to pwdLastSet for user class objects

and again possibly

6. RP to pwdLastSet for user class objects

 

Again, AdMod only needs those first two permissions and really should only need the first.

 

   joe

 

[1] Like you have cleaned up Pre-Windows 2000 Compatible Access.  

[2] I say seemingly because maybe it can if you wheeze and utter the opening to the Rings trilogy while thinking of Star Trek Voyager episodes that feature 7 of 9[3] it can be done but thankfully I am not dependent on ADSI… I love the LDAP API which is not, let me repeat, is NOT the same as the LDAP:// ADSI provider even though they look the same in name. The .NET framework can do real LDAP but I expect most NET apps by default are using the stuff that thunks down to the LDAP:// ADSI provider which then eventually thunks down to real LDAP. On the positive side, your hand has been held and you have likely been protected from doing something incorrectly… On the negative side, you can no longer afford the lollypop you wanted due to the overhead and poor conversion rate of your currency.

[3] All of which combined turns out out to be one of the more powerful geek prayers.

This question comes up so often I decided to write a little something something on it so I can point people at it instead of rewriting the answer.

So let’s say the questions comes in like

Question:

How do I query AD for all users (or objects or whatever) that don’t have “Allow inheritable permissions to propagate to this object…” or words to that effect?

Answer:

You don’t.

🙂

 

Ok so likely not the answer you were looking for nor expecting? The full answer is this…

You can’t because that information is stored in the Security Descriptor which is a big hunk of binary digits called a BLOB or binary blob that you can’t realistically query for anything useful. WHAT?!? That’s an outrage! This MUST be a bug! No, not at all.

This BLOB or chunk of info looks something like

0100149ce0020000fc020000140000008c0000000400780002000000075a38002000000003000000be3b
0ef3f09fd111b6030000f80367c1a57a96bfe60dd011a28500aa003049e2010100000000000100000000
075a38002000000003000000bf3b0ef3f09fd111b6030000f80367c1a57a96bfe60dd011a28500aa0030
49e201010000000000010000000004005402100000000502380010000000030000006d9ec6b7c72cd211
854e00a0c983f6089c7a96bfe60dd011a28500aa003049e2010100000000000509000000050a38001000
0000030000006d9ec6b7c72cd211854e00a0c983f608867a96bfe60dd011a28500aa003049e201010000
0000000509000000050a380010000000030000006d9ec6b7c72cd211854e00a0c983f608ba7a96bfe60d
d011a28500aa003049e201010000000000050900000005002c0010000000010000001db1a946ae605a40
b7e8ff8a58d456d20102000000000005200000003002000005022c0094000200020000009c7a96bfe60d
d011a28500aa003049e20102000000000005200000002a020000050a2c00940002000200000014cc2848
3714bc459b07ad6f015e5f280102000000000005200000002a020000050a2c009400020002000000ba7a
96bfe60dd011a28500aa003049e20102000000000005200000002a020000050028000001000001000000
551a72ab2f1ed011981900aa0040529b01010000000000050b00000000002400ff010f00010500000000
000515000000aa867905c1c5484bba6236d50002000000022400ff010f00010500000000000515000000
aa867905c1c5484bba6236d50702000000001800ff010f00010200000000000520000000240200000002
1800040000000102000000000005200000002a02000000021800bd010f00010200000000000520000000
20020000000014009400020001010000000000050a000000000014009400020001010000000000050b00
000000001400ff010f00010100000000000512000000010500000000000515000000aa867905c1c5484b
ba6236d500020000010500000000000515000000aa867905c1c5484bba6236d50102000030

Now mind you, this is a really small security descriptor, this is a the Security Descriptor on an object that isn’t inheriting anything in a domain with almost all default ACLing. You get a Security Descriptor on a normal production domain with Exchange and LCS and other apps that do crappy things to your ACLs and it will be HUGE compared to this.

So, now that you know what the feared blob looks like and you know that you should be able to easily query it for say whether or not the DACL is protected from inheritance… how about you actually point at that actual part in the above blob that tells someone that the DACL is protected… If you can do that, is it something that could be uniquely found within that string of numbers??? For instance, if you said return all objects with a 2 in the security descriptor, that is almost certainly going to return every single object… Oh… Not quite so easy, eh[1]? 

So that leaves what… exactly?

It leaves you at the point that you have to enumerate the security descriptors and filter out the info that you want. This means returning a lot of data from your DC and filtering through it which isn’t as fast nor as efficient as a query. Oi![2]

So how do we do this…

Why you use AdFind of course!

AdFind will output the SDDL format of Security Descriptors for you. You just use the handy dandy -sddl family of switches and use grep or find or findstr or what not to filter out the lines you care about.

You could do this for some time with AdFind but the most recent set of changes I made fixed a couple of bugs from the last version that could get make it a little more difficult to accomplish plus I added some switches to make it even easier that it would have been before.

So let’s say I had version V01.33.00, I could get a list of the objects that had inheritance off with a command like:

adfind -default -f * ntsecuritydescriptor -sddl -sdna -csv |grep -c “] P”

That would dump the Owner, Group, and DACL of the security descriptor for all objects and then use GREP to filter out any lines that basically had this string in the output – [DACL] PAI.

The output would look something like

G:\Dev\CPP\AdFind>v01.33.00\adfind -default -f * ntsecuritydescriptor -sddl -sdna -csv |grep “] P”

File STDIN:
“CN=VolumeTable,CN=FileLinks,CN=System,DC=test,DC=loc”,”[OWNER] DA;[GROUP] DA;[DACL] PAI(A;;CCDCLCSWRPWPLOCRRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;CI;CCLCSWRPWPLOCRSDR
CWDWO;;;BA)(A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;EA)”

“CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=test,DC=loc”,”[OWNER] DA;[GROUP] DA;[DACL] PAI(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CIIO;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED)”

“CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=test,DC=loc”,”[OWNER] DA;[GROUP] DA;[DACL] PAI(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CIIO;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED)”

“CN=AdminSDHolder,CN=System,DC=test,DC=loc”,”[OWNER] DA;[GROUP] DA;[DACL] PAI(A;;LCRPLORC;;;AU)(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;EA)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;LCRPLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;LCRPLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)”

<SNIP>

Unfortunately I commented out a line in V01.34.00 which would make this not work so you had to do something more like

adfind -default -f * ntsecuritydescriptor -sddl -rawsddl -sdna -csv |grep “D:P”

which resulted in output that looked like

G:\Dev\CPP\AdFind>v01.34.00\adfind -default -f * ntsecuritydescriptor -sddl -rawsddl -sdna -csv |grep “D:P”

File STDIN:
“CN=VolumeTable,CN=FileLinks,CN=System,DC=test,DC=loc”,”[SDDL] O:DAG:DAD:PAI(A;;CCDCLCSWRPWPLOCRRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;CI;CCLCSWRPWPLOCRSDRCWDWO;;;BA)(A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;EA);[OWNER] DA;[GROUP] DA;[DACL] (A;;CCDCLCSWRPWPLOCRRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;CI;CCLCSWRPWPLOCRSDRCWDWO;;;BA)(A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;EA)”

“CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=test,DC=loc”,”[SDDL] O:DAG:DAD:PAI(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CIIO;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED);[OWNER] DA;[GROUP] DA;[DACL] (A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CIIO;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED)”

“CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=test,DC=loc”,”[SDDL] O:DAG:DAD:PAI(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CIIO;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED);[OWNER] DA;[GROUP] DA;[DACL] (A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CIIO;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED)”

“CN=AdminSDHolder,CN=System,DC=test,DC=loc”,”[SDDL] O:DAG:DAD:PAI(A;;LCRPLORC;;;AU)(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;EA)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;LCRPLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;LCRPLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561);[OWNER] DA;[GROUP] DA;[DACL] (A;;LCRPLORC;;;AU)(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;EA)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;DA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;LCRPLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP
;4c164200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;LCRPLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)”

That certainly isn’t winning any awards for simplicity, readability, and elegance.

So I added some new switches specifically for looking for this kind of stuff… Those switches being the -onlydaclflag, -onlysaclflag, and onlyaclflags. Now you can enter a command like

adfind -default -f * ntsecuritydescriptor -sddl -onlydaclflag -csv |grep “] P”

and get output that looks like

G:\new1\Dev\CPP\AdFind>v01.35.00\adfind -default -f * ntsecuritydescriptor -sddl -onlydaclflag -csv |grep “] P”

File STDIN:
“CN=VolumeTable,CN=FileLinks,CN=System,DC=test,DC=loc”,”[DACL] PAI”
“CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=test,DC=loc”,”[DACL] PAI”
“CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=test,DC=loc”,”[DACL] PAI”
“CN=AdminSDHolder,CN=System,DC=test,DC=loc”,”[DACL] PAI”

Hmmmm much better and now you can actually read what is going on there right?

You can also do something like

adfind -default -f * ntsecuritydescriptor -sddl++ -onlydaclflag -csv |grep “FLAGS:PROTECTED”

which results in output like

G:\Dev\CPP\AdFind>v01.35.00\adfind -default -f * ntsecuritydescriptor -sddl++ -onlydaclflag -csv |grep “FLAGS:PROTECTED”

File STDIN:
“CN=VolumeTable,CN=FileLinks,CN=System,DC=test,DC=loc”,”[DACL] (FLAGS:PROTECTED INHERIT)”
“CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=test,DC=loc”,”[DACL] (FLAGS:PROTECTED INHERIT)”
“CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=test,DC=loc”,”[DACL] (FLAGS:PROTECTED INHERIT)”
“CN=AdminSDHolder,CN=System,DC=test,DC=loc”,”[DACL] (FLAGS:PROTECTED INHERIT)”

Which some people may like better.

The difference between those two commands is the changing of -sddl to -sddl++ which forces AdFind to do some more string decoding for you. Note that it will require more overhead and go a little slower but may look nicer for you.

The other item that is different from the command previous is the addition of the -onlydaclflag switch which tells AdFind to only request the DACL and skip the Owner, Group, and SACL info of the Security Descriptor, this results in less work for the DC and less data over the wire. Unfortunately you still have to bring the whole DACL over but only the flags for that ACL are displayed.

You can do this against a Global Catalog if you would like as well to find ALL objects in the forest that have inheritance blocked… I just ran the following command

adfind -h 2k3dc02 -gc -null -f * ntsecuritydescriptor -sddl -onlydaclflag -csv |grep “] P”

against a low end test DC with 256MB of RAM holding about 39000 objects and found the 84 objects with blocked inheritance in 41 seconds. Running the same thing but using the -sddl++ and the longer match string took 45 seconds which makes sense as there is more work per object to be done. Either way, how long would it take you to find those matches before? Maybe before you couldn’t without having someone supply you with a script or some expensive third party tool.

Hope folks find this entry and the modifications to AdFind useful. Certainly it felt good on my end to do purely technical work to write this up and modify AdFind especially involving Active Directory versus all of the stuff I have been having to work on lately.

 

   joe

 

[1] I was receiving complaints from north of the border that I didn’t have enough Canadian content in my posts so there you go…

[2] Hello to my Australian/British friends.