joeware - never stop exploring... :)

This one isn’t from my personal inbox but from a thread on ActiveDir Org a little while ago. I wanted to post it to the blog as well because I actually think I get a little wider audience here and this blog seems to be popular with the search engines and this is good info to share with folks because they truly are pretty common questions.

The original post:

Hi,

We have the UNIX attibs added in your AD with uidNumber and gidNumber etc. One part of our file storage uses UNIX rights (with gidNumber). The goal is to transfer the group definitions from the file storage into the AD, but I have a concern.

We delegate rights to create groups on various places (every department have their own OU where they can create groups and other objects). If we have a group with a certain gidNumber centrally, what stops a creative admin to create another group (with a different name), but with the same gidNumber and then access the UNIX share?

I can think of two solutions on this problem:

1. Is it possible to modify the attribute to only allow unique values?

2. Is it possible to add ACL:s to the attribute (in the schema) so only a service account have write access?

Thank you

Here is my response to the post…

1. No. The OS does not have that functionality available to enable/disable for attributes, would be nice though. 😉 The MSFT answer here is that all of your provisioning should be handled through a provisioning tool such as FIM which allows you to configure business rules such as this.

2. No. If you give someone the ability to create groups, it is entirely up to them what the ACL will be on that object when they create it or even after they create it if you allow default creator/owner functionality. The defaultSecurityDescriptor in the Schema is *only* used when a security descriptor is not specified in the object create. Granted this is the default most of the time, but if someone is looking to side step you, it is less than trivial to do so if you have granted CREATE rights.

For an example of #2…

This  first request creates a group using the default security descriptor (because I didn’t specify one)

C:\>admod -default -rb cn=group1,ou=defaultsdtest -add objectclass::group

AdMod V01.12.00cpp Joe Richards (joe@joeware.net) February 2010

DN Count: 1
Using server: TEST-DC1.test.loc:389
Directory: Windows Server 2003
Base DN: cn=group1,ou=defaultsdtest,DC=test,DC=loc

Adding specified objects…
   DN: cn=group1,ou=defaultsdtest,DC=test,DC=loc…

The command completed successfully

 

This second request creates a group using the security descriptor I want

 

C:\>admod -default -rb cn=group2,ou=defaultsdtest -add objectclass::group SD##ntsecuritydescriptor::D:P(A;;GA;;;WD)

AdMod V01.12.00cpp Joe Richards (joe@joeware.net) February 2010

DN Count: 1

Using server: TEST-DC1.test.loc:389

Directory: Windows Server 2003

Base DN: cn=group2,ou=defaultsdtest,DC=test,DC=loc

Adding specified objects…

   DN: cn=group2,ou=defaultsdtest,DC=test,DC=loc…

The command completed successfully

 

And here is what AD has for the ACL for group1

 

C:\>dsacls cn=group1,ou=defaultsdtest,DC=test,DC=loc

Access list:

Effective Permissions on this object are:

Allow TEST\Domain Admins                          FULL CONTROL

Allow BUILTIN\Account Operators                   FULL CONTROL

Allow NT AUTHORITY\SELF                           SPECIAL ACCESS

                                                  READ PERMISSONS

                                                  LIST CONTENTS

                                                  READ PROPERTY

                                                  LIST OBJECT

Allow NT AUTHORITY\Authenticated Users            SPECIAL ACCESS

                                                  READ PERMISSONS

                                                  LIST CONTENTS

                                                  READ PROPERTY

                                                  LIST OBJECT

Allow NT AUTHORITY\SYSTEM                         FULL CONTROL

Allow BUILTIN\Pre-Windows 2000 Compatible Access  SPECIAL ACCESS   <Inherited from parent>

                                                  READ PERMISSONS

                                                  LIST CONTENTS

                                                  READ PROPERTY

                                                  LIST OBJECT

Allow TEST\Enterprise Admins                      FULL CONTROL   <Inherited from parent>

Allow BUILTIN\Pre-Windows 2000 Compatible Access  SPECIAL ACCESS   <Inherited from parent>

                                                  LIST CONTENTS

Allow BUILTIN\Administrators                      SPECIAL ACCESS   <Inherited from parent>

                                                  DELETE

                                                  READ PERMISSONS

                                                  WRITE PERMISSIONS

                                                  CHANGE OWNERSHIP

                                                  CREATE CHILD

                                                  LIST CONTENTS

                                                  WRITE SELF

                                                  WRITE PROPERTY

                                                 READ PROPERTY

                                                  LIST OBJECT

                                                  CONTROL ACCESS

Allow BUILTIN\Windows Authorization Access Group  SPECIAL ACCESS for tokenGroupsGlobalAndUniversal

                                                  READ PROPERTY

Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS  SPECIAL ACCESS for tokenGroups   <Inherited from parent>

                                                  READ PROPERTY

Allow NT AUTHORITY\Authenticated Users            Send To

Permissions inherited to subobjects are:

Inherited to all subobjects

Allow TEST\Enterprise Admins                      FULL CONTROL   <Inherited from parent>

Allow BUILTIN\Pre-Windows 2000 Compatible Access  SPECIAL ACCESS   <Inherited from parent>

                                                  LIST CONTENTS

Allow BUILTIN\Administrators                      SPECIAL ACCESS   <Inherited from parent>

                                                  DELETE

                                                  READ PERMISSONS

                                                  WRITE PERMISSIONS

                                                  CHANGE OWNERSHIP

                                                  CREATE CHILD

                                                  LIST CONTENTS

                                                  WRITE SELF

                                                  WRITE PROPERTY

                                                  READ PROPERTY

                                                  LIST OBJECT

                                                  CONTROL ACCESS

Inherited to user

Allow BUILTIN\Pre-Windows 2000 Compatible Access  SPECIAL ACCESS   <Inherited from parent>

                                                  READ PERMISSONS

                                                  LIST CONTENTS

                                                  READ PROPERTY

                                                  LIST OBJECT

Inherited to inetOrgPerson

Allow BUILTIN\Pre-Windows 2000 Compatible Access  SPECIAL ACCESS   <Inherited from parent>

                                                  READ PERMISSONS

                                                  LIST CONTENTS

                                                  READ PROPERTY

                                                  LIST OBJECT

Inherited to user

Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS  SPECIAL ACCESS for tokenGroups   <Inherited from parent>

                                                  READ PROPERTY

Inherited to computer

Allow NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS  SPECIAL ACCESS for tokenGroups   <Inherited from parent>

                                                  READ PROPERTY

The command completed successfully

 

And here is the ACL that AD has for group2.

 

C:\>dsacls cn=group2,ou=defaultsdtest,DC=test,DC=loc

Access list:

{This object is protected from inheriting permissions from the parent}

Effective Permissions on this object are:

Allow Everyone  FULL CONTROL

The command completed successfully

 

As you can see I effectively killed the inheritance for any permissions flowing down from above and I have taken the defaultSecurityDescriptor out of the picture.

 

A quick comment on Brian’s response too. He mentioned

2: Yes and no. You could restrict the ability to write to gidNumber on objects of group class, however, if you’ve given the ability to create objects of the group class to anyone, or full control of groups, then they can circumvent that ACL. Explicit Allow ACEs trump inherited Deny ACEs in AD. And object owners (by default whoever creates an object) have full control.

Assuming the defaultSecurityDescriptor was used to add the DENY modify of gidNumber, it would be applied as an explicit DENY and therefore override the creator’s explicit FC for the object. However, as mentioned above, the defaultSecurityDescriptor is moot. But also… if the creator has FC applied, even with an explicit DENY, they will just modify the ACL on the object to remove the explicit DENY and voila, they are in the game yet again.

BTW, another fun point here… Some people try to circumvent this security issue by having an agent constantly monitoring ACLs and “correcting” the “bad” ones when found. This can also be beaten, once the person finds out what the security context of the agent is running in (assuming not localsystem on DCs as that is discouraged as a best practice right?), you just set up the DACL that you lay down on the object to deny FC for that object and then the agent has no power over the object if it even sees it at all (it won’t be returned in queries right?). Maybe it will flag an error, maybe it won’t, depending on how well it was written. Maybe the flagged error will be looked at by an administrator, maybe it won’t, depending on how well that process is being managed/supported.

As Brian indicated, the proper way to handle this is to not allow people to create groups natively. Provisioning as a general statement should be done through a gatekeeper system, either a team that is responsible strictly for provisioning or a tool that does it. Giving random folks ability to create objects in AD is in general a bad idea. It should be a team or person that is dedicated to that function and on the hook to know and follow the rules. 

joe

I received an email the likes of which I have seen a few times over the last few years and figured I would share the issue and my response.

The issue is someone who has a bunch of machines scattered around a very large environment and they really don’t know what domain those machines are in, if any. Now I expect there are folks out there reading this who are absolutely incredulous over the fact that you could have machines in the environment and not even know if they are in a domain or if they are in a domain, what domain that might be. Unfortunately I have to say that that happens rather regularly in the larger environments where you have hundreds if not thousands of machines and you actually, I am not lying, have even tens or hundreds of domains laying about the network.

There will be machines in the environment and actually forgotten for years once the person who was responsible for them moves on or gets fired or whatever. I recall once that I found a very super high powered server (Quad Proc when even a Dual Proc was pretty darn cool) that was probably 5-10 times more powerful than most of the stuff I got to use that was just sitting and spinning idle. Had been in that state for over three years. Someone had a hot project that needed a hot server, they paid for it up front, it got deployed, then something happened and the project died and no one came and reclaimed it. It wasn’t listed in any of the standard support databases, not in AD, nothing. I only found it because it was infected with something and beating the network up trying to infect other machines.

Anyway, the basic problem is, say you have an IP or a resolvable machine name but you don’t know what domain that machine is part of and need to determine that info remotely. Yes, I know the quick answer is, well whatever the domain suffix it has on it, that is the domain it is part of. That is the quick answer, but it could very likely be the wrong answer. There is no rule that states a machine has to be a member of a given domain in order to have that domain as its DNS suffix.

The quickest and easiest solution I am aware of kind of old school and will slowly become less and less useful. The idea is to enumerate the NetBIOS Name table for the machine and work out what the records are. Obviously, machine based firewalls and turning off NetBIOS can impact this, both of which are becoming more common and why I said this idea will slowly become less and less useful.

Here are some examples:

G:\>nbtstat -a joeware-dc1

Local Area Connection:
Node IpAddress: [192.168.0.122] Scope Id: []

           NetBIOS Remote Machine Name Table

       Name               Type         Status
    ———————————————
    JOEWARE-DC1    <00>  UNIQUE      Registered
    JOEWARE        <00>  GROUP       Registered
    JOEWARE        <1C>  GROUP       Registered
    JOEWARE-DC1    <20>  UNIQUE      Registered
    JOEWARE        <1B>  UNIQUE      Registered
    JOEWARE        <1E>  GROUP       Registered
    JOEWARE        <1D>  UNIQUE      Registered
    ..__MSBROWSE__.<01>  GROUP       Registered

    MAC Address = 00-0C-29-F4-7B-5E

Note if you had the IP you would use NBSTAT -A IPADDRESS  (note the cap –A switch)

From that name table you can see that this machine has the <00> and <1E> group records for JOEWARE which means it is a member of the JOEWARE domain. Not only that, but it also has a <1C> group record for JOEWARE which means it is a domain controller for JOEWARE…. And not only that… It has a <1B> record for JOEWARE which means it is the PDC for JOEWARE. The only catch here is… JOEWARE is a NetBIOS name, the DNS name could be anything. Thankfully since it is a DC, you can (assuming not Windows NT) query the RootDSE and get more data like so:

G:\>adfind -h joeware-dc1 -rootdseanon

AdFind V01.41.00cpp Joe Richards (joe@joeware.net) February 2010

Using server: JOEWARE-DC1.joeware.local:389
Directory: Windows Server 2003

dn:
>currentTime: 20101123194337.0Z
>subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=joeware,DC=local
>dsServiceName: CN=NTDS Settings,CN=JOEWARE-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=joeware,DC=local
>namingContexts: DC=joeware,DC=local
>namingContexts: CN=Configuration,DC=joeware,DC=local
>namingContexts: CN=Schema,CN=Configuration,DC=joeware,DC=local
>namingContexts: DC=DomainDnsZones,DC=joeware,DC=local
>namingContexts: DC=ForestDnsZones,DC=joeware,DC=local
>defaultNamingContext: DC=joeware,DC=local
>schemaNamingContext: CN=Schema,CN=Configuration,DC=joeware,DC=local
>configurationNamingContext: CN=Configuration,DC=joeware,DC=local
>rootDomainNamingContext: DC=joeware,DC=local
>supportedControl: 1.2.840.113556.1.4.319 [LDAP_PAGED_RESULT_OID_STRING]
>supportedControl: 1.2.840.113556.1.4.801 [LDAP_SERVER_SD_FLAGS_OID]
>supportedControl: 1.2.840.113556.1.4.473 [LDAP_SERVER_SORT_OID]
>supportedControl: 1.2.840.113556.1.4.528 [LDAP_SERVER_NOTIFICATION_OID]
>supportedControl: 1.2.840.113556.1.4.417 [LDAP_SERVER_SHOW_DELETED_OID]
>supportedControl: 1.2.840.113556.1.4.619 [LDAP_SERVER_LAZY_COMMIT_OID]
>supportedControl: 1.2.840.113556.1.4.841 [LDAP_SERVER_DIRSYNC_OID]
>supportedControl: 1.2.840.113556.1.4.529 [LDAP_SERVER_EXTENDED_DN_OID]
>supportedControl: 1.2.840.113556.1.4.805 [LDAP_SERVER_TREE_DELETE_OID]
>supportedControl: 1.2.840.113556.1.4.521 [LDAP_SERVER_CROSSDOM_MOVE_TARGET_OID]
>supportedControl: 1.2.840.113556.1.4.970 [LDAP_SERVER_GET_STATS_OID]
>supportedControl: 1.2.840.113556.1.4.1338 [LDAP_SERVER_VERIFY_NAME_OID]
>supportedControl: 1.2.840.113556.1.4.474 [LDAP_SERVER_RESP_SORT_OID]
>supportedControl: 1.2.840.113556.1.4.1339 [LDAP_SERVER_DOMAIN_SCOPE_OID]
>supportedControl: 1.2.840.113556.1.4.1340 [LDAP_SERVER_SEARCH_OPTIONS_OID]
>supportedControl: 1.2.840.113556.1.4.1413 [LDAP_SERVER_PERMISSIVE_MODIFY_OID]
>supportedControl: 2.16.840.1.113730.3.4.9 [LDAP_CONTROL_VLVREQUEST]
>supportedControl: 2.16.840.1.113730.3.4.10 [LDAP_CONTROL_VLVRESPONSE]
>supportedControl: 1.2.840.113556.1.4.1504 [LDAP_SERVER_ASQ_OID]
>supportedControl: 1.2.840.113556.1.4.1852 [LDAP_SERVER_QUOTA_CONTROL_OID]
>supportedControl: 1.2.840.113556.1.4.802 [LDAP_SERVER_RANGE_OPTION_OID]
>supportedControl: 1.2.840.113556.1.4.1907 [LDAP_SERVER_SHUTDOWN_NOTIFY_OID]
>supportedControl: 1.2.840.113556.1.4.1948 [LDAP_SERVER_RANGE_RETRIEVAL_NOERR]
>supportedLDAPVersion: 3
>supportedLDAPVersion: 2
>supportedLDAPPolicies: MaxPoolThreads
>supportedLDAPPolicies: MaxDatagramRecv
>supportedLDAPPolicies: MaxReceiveBuffer
>supportedLDAPPolicies: InitRecvTimeout
>supportedLDAPPolicies: MaxConnections
>supportedLDAPPolicies: MaxConnIdleTime
>supportedLDAPPolicies: MaxPageSize
>supportedLDAPPolicies: MaxQueryDuration
>supportedLDAPPolicies: MaxTempTableSize
>supportedLDAPPolicies: MaxResultSetSize
>supportedLDAPPolicies: MaxNotificationPerConn
>supportedLDAPPolicies: MaxValRange
>highestCommittedUSN: 741310
>supportedSASLMechanisms: GSSAPI
>supportedSASLMechanisms: GSS-SPNEGO
>supportedSASLMechanisms: EXTERNAL
>supportedSASLMechanisms: DIGEST-MD5
>dnsHostName: JOEWARE-DC1.joeware.local
>ldapServiceName: joeware.local:joeware-dc1$@JOEWARE.LOCAL
>serverName: CN=JOEWARE-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=joeware,DC=local
>supportedCapabilities: 1.2.840.113556.1.4.800 [LDAP_CAP_ACTIVE_DIRECTORY_OID]
>supportedCapabilities: 1.2.840.113556.1.4.1670 [LDAP_CAP_ACTIVE_DIRECTORY_V51_OID]
>supportedCapabilities: 1.2.840.113556.1.4.1791 [LDAP_CAP_ACTIVE_DIRECTORY_LDAP_INTEG_OID]
>dsSchemaAttrCount: 1980
>dsSchemaClassCount: 361
>dsSchemaPrefixCount: 47
>isSynchronized: TRUE
>isGlobalCatalogReady: TRUE
>supportedConfigurableSettings: DynamicObjectDefaultTTL
>supportedConfigurableSettings: DynamicObjectMinTTL
>supportedConfigurableSettings: DisableVLVSupport
>supportedExtension: 1.3.6.1.4.1.1466.20037 [LDAP_SERVER_START_TLS_OID]
>supportedExtension: 1.3.6.1.4.1.1466.101.119.1 [LDAP_TTL_REFRESH_OID]
>supportedExtension: 1.2.840.113556.1.4.1781 [LDAP_SERVER_FAST_BIND_OID]
>domainFunctionality: 2 [Windows Server 2003 Domain Mode]
>forestFunctionality: 2 [Windows Server 2003 Forest Mode]
>domainControllerFunctionality: 2 [Windows Server 2003 Mode]
>validFSMOs: CN=Schema,CN=Configuration,DC=joeware,DC=local
>validFSMOs: CN=Partitions,CN=Configuration,DC=joeware,DC=local
>validFSMOs: DC=joeware,DC=local
>validFSMOs: CN=Infrastructure,DC=joeware,DC=local
>validFSMOs: CN=RID Manager$,CN=System,DC=joeware,DC=local

1 Objects returned

That extra info, available because it is a DC, really lets us know what is going on with that machine. Best of all, it is all anonymous, no need for creds if you even knew what creds to use… In fact, the reason for this exercise could be to try and ascertain what ID you should be using.

Unfortunately, a machine that isn’t a DC isn’t quite as helpful but perhaps it does give enough info.

G:\>nbtstat -a mbx01

Local Area Connection:
Node IpAddress: [192.168.0.122] Scope Id: []

           NetBIOS Remote Machine Name Table

       Name               Type         Status
    ———————————————
    MBX01          <00>  UNIQUE      Registered
    JOEWARE        <00>  GROUP       Registered
    MBX01          <20>  UNIQUE      Registered
    JOEWARE        <1E>  GROUP       Registered

    MAC Address = 00-0C-29-64-4D-D7

The <00> and <1E> Group records again tell you the domain, but that is about all you get out of this one. Occasionally you will find that if you portscan the machine, you will find a port for some common service, say SMTP that may give you more info, that can be enough to get you going in the right direction.

Overall, I see this issue getting more and more difficult to handle as we move forward and lock machines down. It has made me recommend to some people that maybe their standard OS loads should have some sort of beacon type functionality in place. If you hit the server on the right port with some simple string, say IDENTIFY, it responds with some basic info about the machine. That port and command would be maintained in a very stringent manner and well tested for string length etc so it doesn’t later become an Achilles heel for the machine but could be very useful for larger orgs that just for the life of them can’t seem to get a handle on stray machines in the environment.

   joe

Hi
I came across your free tools and think these tools are very much what any administrator needs but it seems that when i downloaded this utility it does nothing. Command box opens and disappears in flash of a second.  I am running Windows 7, any idea? Any help would much appreciated.

Thanks
xxx
IT Desktop Support

To all computer admins, if  you click on an application and a command prompt flashes on the screen, the likely next step is to open a command prompt and type in the command and try that. 

     joe

A notorious rootkit that for years has ravaged 32-bit versions of Windows has begun claiming 64-bit versions of the Microsoft operating system as well.

The ability of TDL, aka Alureon, to infect 64-bit versions of Windows 7 is something of a coup for its creators, because Microsoft endowed the OS with enhanced security safeguards that were intended to block such attacks. The rootkit crossed into the 64-bit realm sometime in August, according to security firm Prevx.

Full article…

http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/