Wednesday, April 22, 2009

Who told AD what OS I’m running?

Have any DOS 1.0 clients in your AD forest? I do.

How’d that get there?

Easy answer.

With Write Property permissions on a computer object, anyone can write any value they desire to the various operatingSystem attributes. However, a few days later our devious admin notices the truth has been revealed.

How’d that get there?

Tougher answer.

Let’s start by reviewing the delegation model AD creates when creating a computer account and allowing a non-Domain Admin to perform a delegated join. Using DSA.MSC, we can pre-create a computer account and delegate rights to our DelegatedAdmins group. One bug to note here, the W2K3 version of DSA.MSC will ACL the delegated workstation account with some invalid GUIDs for the inherited object type. We can see these with LDP as the zero GUIDs that don’t resolve to a real inherited object type.

The W2K3 version of DSACLs will also crash due to the invalid GUIDs and will not display the ACLs. The W2K8 version does not crash, so we can see the output (which is a useful feature).

I don’t see anything obviously allowing either the delegated admin or the computer account itself to be able to write the operatingSystem values. Account Restrictions and Logon Information are both property sets. Let’s see what attributes they contain.

This shows us most of the attributes were written at the start of the join process. Most have a version number of 1, with the same originating timestamp. However, looking closely, we can see there are really four groups of updates. The first were stamped at 22:57:54 and correspond to the creation of the computer object by the Domain Admin. The second was stamped at 22:58:19 and represents the setting of the password secrets. The third was stamped at 22:58:20 and represents the population of the dnsHostName and servicePrincipalName attributes. The final group was timestamped three seconds later at 22:58:23, and shows the operatingSystem, operatingSystemVersion and operatingSystemServicePack attributes being set. Since this group was updated later, that means it probably wasn’t done as part of the join process, which is good since we’re pretty sure we didn’t delegate the right to write to those attributes.

The join process has fairly decent debug data written to the %windir%\debug\netsetup.log file. Cracking that logfile open shows us the following events.

This confirms the data we saw from RepAdmin. The NetpLsaOpenSecret occurs at 22:58:19, and dnsHostName and servicePrincipalName attributes were set at 22:58:20. The join succeeds at 22:58:20, which is also the end of the logfile. Obviously setting the OS attributes isn’t part of the join process.

For the ultimate truth, nothing beats a capture of packets on the wire. With this, we can correlate everything we’ve seen with real network traffic. First we see the join initiate and succeed, and it is easy to correlate the NetpGetComputerObjectDn in the logfile and its “cracking DNS domain name” comment with the DSRCrackNames Request in the packet capture.

The join process is followed by establishment of the secure channel, which matches the timestamp difference the metadata showed us.

This packet toward the end of the capture has a fairly large encrypted blob.

Too bad the parsers don’t automatically bust open the packets, since they were captured from one of the two systems involved in the secure communication, and should have access to the private keys. However, doing a search for NetrLogonGetDomainInfo leads us to the MS-NRPC protocol specification that Microsoft released in 2008. Specifically section 2.2.1.3.6 NETLOGON_WORKSTATION_INFO details that the structure does in fact contain both OsVersion and OsName values.

There we finally have it. During the setup of the secure channel, the Microsoft clients embed details about their OS configuration. The Domain Controller receiving this information dutifully applies it to the OS attributes of the computer object. So even if an admin were granted full control over their computer object, they’ll be constantly fighting Windows’ attempts to ensure the correct OS information is written to the object.