Gotta Get Back In Time

I’m just amazed by our ability to peer back in time.

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).

C:\>dsacls \\dc01.ad.test\cn=workstation1,cn=computers,dc=ad,dc=test
Owner: AD\Domain Admins
Group: AD\Domain Users

Access list:
Allow AD\DelegatedAdmins SPECIAL ACCESS
DELETE
READ PERMISSONS
LIST CONTENTS
READ PROPERTY
DELETE TREE
LIST OBJECT
CONTROL ACCESS
Allow AD\DelegatedAdmins SPECIAL ACCESS for Account Restrictions
WRITE PROPERTY
Allow AD\DelegatedAdmins SPECIAL ACCESS for sAMAccountName
WRITE PROPERTY
Allow AD\DelegatedAdmins SPECIAL ACCESS for Logon Information
WRITE PROPERTY
Allow AD\DelegatedAdmins SPECIAL ACCESS for description
WRITE PROPERTY
Allow AD\DelegatedAdmins SPECIAL ACCESS for displayName
WRITE PROPERTY
Allow AD\DelegatedAdmins SPECIAL ACCESS for Validated write to DNS host name
WRITE SELF
Allow AD\DelegatedAdmins SPECIAL ACCESS for Validated write to service principal name
WRITE SELF
Allow NT AUTHORITY\SELF SPECIAL ACCESS for Personal Information
WRITE PROPERTY
READ PROPERTY
Allow NT AUTHORITY\SELF SPECIAL ACCESS
CREATE CHILD
DELETE CHILD
Allow NT AUTHORITY\SELF SPECIAL ACCESS for Validated write to service principal name
WRITE SELF
Allow NT AUTHORITY\SELF SPECIAL ACCESS for Validated write to DNS host name
WRITE SELF

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.

C:\>adfind -sc findpropsetrg:"Account Restrictions"

AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009

Using server: dc01.ad.test:389
Directory: Windows Server 2003
Base DN: cn=extended-rights,CN=Configuration,DC=ad,DC=test

dn:CN=User-Account-Restrictions,CN=Extended-Rights,CN=Configuration,DC=ad,DC=test
>rightsGuid: 4c164200-20c0-11d0-a768-00aa006e0529

1 Objects returned

C:\>adfind -sc propsetmembers:4c164200-20c0-11d0-a768-00aa006e0529 -dn

AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009

Transformed Filter: (&(objectcategory=attributeschema)(attributeSecurityGUID=\00
B\16L\C0\20\D0\11\A7h\00\AA\00n\05\29))
Using server: dc01.ad.test:389
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=ad,DC=test

dn:CN=Account-Expires,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=ms-DS-User-Account-Control-Computed,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Pwd-Last-Set,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=User-Account-Control,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=User-Parameters,CN=Schema,CN=Configuration,DC=ad,DC=test

5 Objects returned

C:\>adfind -sc findpropsetrg:"Logon Information"

AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009

Using server: dc01.ad.test:389
Directory: Windows Server 2003
Base DN: cn=extended-rights,CN=Configuration,DC=ad,DC=test

dn:CN=User-Logon,CN=Extended-Rights,CN=Configuration,DC=ad,DC=test
>rightsGuid: 5f202010-79a5-11d0-9020-00c04fc2d4cf

1 Objects returned

C:\>adfind -sc propsetmembers:5f202010-79a5-11d0-9020-00c04fc2d4cf -dn

AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009

Transformed Filter: (&(objectcategory=attributeschema)(attributeSecurityGUID=\10
\20\20\5F\A5y\D0\11\90\20\00\C0O\C2\D4\CF))
Using server: dc01.ad.test:389
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=ad,DC=test

dn:CN=Bad-Pwd-Count,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Home-Directory,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Home-Drive,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Last-Logoff,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Last-Logon,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Last-Logon-Timestamp,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Logon-Count,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Logon-Hours,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Logon-Workstation,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Profile-Path,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=Script-Path,CN=Schema,CN=Configuration,DC=ad,DC=test
dn:CN=User-Workstations,CN=Schema,CN=Configuration,DC=ad,DC=test

12 Objects returned

Even with the property sets, I still don’t see anything granting write access to the operatingSystem attributes.

We’re not sure who wrote the data, maybe when it was written can provide a clue. The replication metadata will reveal when attributes received an originating update.

C:\>repadmin /showobjmeta localhost cn=workstation1,cn=computers,dc=ad,dc=test

29 entries.

Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute

======= =============== ========= ============= === =========

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 objectClass

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 cn

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 instanceType

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 whenCreated

13878 Default-First-Site-Name\DC01 13878 2009-04-08 22:57:54 2 nTSecurityDescriptor

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 name

13883 Default-First-Site-Name\DC01 13883 2009-04-08 22:58:19 5 userAccountControl

13875 Default-First-Site-Name\DC01 13875 2009-04-08 22:57:54 1 codePage

13875 Default-First-Site-Name\DC01 13875 2009-04-08 22:57:54 1 countryCode

13884 Default-First-Site-Name\DC01 13884 2009-04-08 22:58:19 3 dBCSPwd

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 localPolicyFlags

13875 Default-First-Site-Name\DC01 13875 2009-04-08 22:57:54 1 logonHours

13884 Default-First-Site-Name\DC01 13884 2009-04-08 22:58:19 3 unicodePwd

13884 Default-First-Site-Name\DC01 13884 2009-04-08 22:58:19 3 ntPwdHistory

13884 Default-First-Site-Name\DC01 13884 2009-04-08 22:58:19 3 pwdLastSet

13875 Default-First-Site-Name\DC01 13875 2009-04-08 22:57:54 1 primaryGroupID

13885 Default-First-Site-Name\DC01 13885 2009-04-08 22:58:19 2 supplementalCredentials

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 objectSid

13875 Default-First-Site-Name\DC01 13875 2009-04-08 22:57:54 1 accountExpires

13884 Default-First-Site-Name\DC01 13884 2009-04-08 22:58:19 3 lmPwdHistory

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 sAMAccountName

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 sAMAccountType

13889 Default-First-Site-Name\DC01 13889 2009-04-08 22:58:23 1 operatingSystem

13889 Default-First-Site-Name\DC01 13889 2009-04-08 22:58:23 1 operatingSystemVersion

13889 Default-First-Site-Name\DC01 13889 2009-04-08 22:58:23 1 operatingSystemServicePack

13887 Default-First-Site-Name\DC01 13887 2009-04-08 22:58:20 1 dNSHostName

13887 Default-First-Site-Name\DC01 13887 2009-04-08 22:58:20 1 servicePrincipalName

13874 Default-First-Site-Name\DC01 13874 2009-04-08 22:57:54 1 objectCategory

13875 Default-First-Site-Name\DC01 13875 2009-04-08 22:57:54 1 isCriticalSystemObject

0 entries.

Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver

======= ============ ============= ================= ======= ======= ===

Distinguished Name

=============================

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.

04/08 22:58:11 -----------------------------------------------------------------
04/08 22:58:11 NetpValidateName: checking to see if 'ad.test' is valid as type 3 name
04/08 22:58:11 NetpCheckDomainNameIsValid [ Exists ] for 'ad.test' returned 0x0
04/08 22:58:11 NetpValidateName: name 'ad.test' is valid for type 3
04/08 22:58:19 -----------------------------------------------------------------
04/08 22:58:19 NetpDoDomainJoin
04/08 22:58:19 NetpMachineValidToJoin: 'WORKSTATION1'
04/08 22:58:19 NetpGetLsaPrimaryDomain: status: 0x0
04/08 22:58:19 NetpMachineValidToJoin: status: 0x0
04/08 22:58:19 NetpJoinDomain
04/08 22:58:19 Machine: WORKSTATION1
04/08 22:58:19 Domain: ad.test
04/08 22:58:19 MachineAccountOU: (NULL)
04/08 22:58:19 Account: ad.test\dloder
04/08 22:58:19 Options: 0x25
04/08 22:58:19 OS Version: 5.2
04/08 22:58:19 Build number: 3790
04/08 22:58:19 ServicePack: Service Pack 2
04/08 22:58:19 NetpValidateName: checking to see if 'ad.test' is valid as type 3 name
04/08 22:58:19 NetpCheckDomainNameIsValid [ Exists ] for 'ad.test' returned 0x0
04/08 22:58:19 NetpValidateName: name 'ad.test' is valid for type 3
04/08 22:58:19 NetpDsGetDcName: trying to find DC in domain 'ad.test', flags: 0x1020
04/08 22:58:19 NetpDsGetDcName: found DC '\\dc01.ad.test' in the specified domain
04/08 22:58:19 NetpJoinDomain: status of connecting to dc '\\dc01.ad.test': 0x0
04/08 22:58:19 NetpGetLsaPrimaryDomain: status: 0x0
04/08 22:58:19 NetpGetDnsHostName: Read NV Hostname: workstation1
04/08 22:58:19 NetpGetDnsHostName: PrimaryDnsSuffix defaulted to DNS domain name: ad.test
04/08 22:58:19 NetpLsaOpenSecret: status: 0xc0000034
04/08 22:58:19 NetpGetLsaPrimaryDomain: status: 0x0
04/08 22:58:19 NetpLsaOpenSecret: status: 0xc0000034
04/08 22:58:20 NetpJoinDomain: status of setting machine password: 0x0
04/08 22:58:20 NetpGetComputerObjectDn: Cracking DNS domain name ad.test/ into Netbios on \\dc01.ad.test
04/08 22:58:20 NetpGetComputerObjectDn: Crack results: name = AD\
04/08 22:58:20 NetpGetComputerObjectDn: Cracking account name AD\WORKSTATION1$ on \\dc01.ad.test
04/08 22:58:20 NetpGetComputerObjectDn: Crack results: (Account already exists) DN = CN=workstation1,CN=Computers,DC=ad,DC=test
04/08 22:58:20 NetpModifyComputerObjectInDs: Initial attribute values:
04/08 22:58:20 DnsHostName = workstation1.ad.test
04/08 22:58:20 ServicePrincipalName = HOST/workstation1.ad.test HOST/WORKSTATION1
04/08 22:58:20 NetpModifyComputerObjectInDs: Computer Object already exists in OU:
04/08 22:58:20 DnsHostName =
04/08 22:58:20 ServicePrincipalName =
04/08 22:58:20 NetpModifyComputerObjectInDs: Attribute values to set:
04/08 22:58:20 DnsHostName = workstation1.ad.test
04/08 22:58:20 ServicePrincipalName = HOST/workstation1.ad.test HOST/WORKSTATION1
04/08 22:58:20 ldap_unbind status: 0x0
04/08 22:58:20 NetpJoinDomain: status of setting DnsHostName and SPN: 0x0
04/08 22:58:20 NetpGetLsaPrimaryDomain: status: 0x0
04/08 22:58:20 NetpSetLsaPrimaryDomain: for 'AD' status: 0x0
04/08 22:58:20 NetpJoinDomain: status of setting LSA pri. domain: 0x0
04/08 22:58:20 NetpJoinDomain: status of managing local groups: 0x0
04/08 22:58:20 NetpJoinDomain: status of setting netlogon cache: 0x0
04/08 22:58:20 NetpJoinDomain: status of setting ComputerNamePhysicalDnsDomain to 'ad.test': 0x0
04/08 22:58:20 NetpUpdateW32timeConfig: 0x0
04/08 22:58:20 NetpJoinDomain: status of disconnecting from '\\dc01.ad.test': 0x0
04/08 22:58:20 NetpDoDomainJoin: status: 0x0

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.

The ID Element

I saw this first on tomek's blog.

Great interview with Stuart Kwan.  I loved his comment on Identity always being an ongoing, yet evolving problem; there will always be a need for solving identity problems as long as interconnected systems exist.  That's what keeps me interested in my job.  Identity really is that base foundation that all apps need.  Talking with my manager recently we had commented that where we are in our enterprise is a great position to hold because we essentially get to tour all areas of the business without ever changing jobs.  I doubt there are few other positions within an enterprise that are as fully connected to so many aspects of the business than those of an identity solutions architect.

Post #1!

 

After a few years of reading the ActiveDir.org mailing list, and subscribing to the major AD blogs (joe, Brian, Jorge – pretty much everyone on ActiveDir!) I’ve decided I’ve got enough years under my belt, and a big enough environment to give me enough topics to hopefully keep this interesting for a while.  Mostly I’m doing this as my small piece to give back to the community that been such a wonderful resource.  Feel free to let me know if you ever find these useful – or not.