Comment Spam from Paramount Defenses

For those of you who know joe, perhaps you remember his past comments on Sanjay and Paramount Defenses.

Earlier today I answered an Active Dir question about how to tell when a machine was domain-joined by pointing the poster to my previous write-up on the domain-join process.  To be able to get the URL for my response, I opened the topic on my blog, which showed me the comments that had been added.  Imagine my surprise when I see a comment from someone named JM from a month ago.  It start with “Thanks for sharing your insightful thoughts and suggestions - very cool and helpful indeed.” (you couldn’t write a more generic opening if you tried) and then launches into a four paragraph sales pitch for GF.

I’m sorry, but my blog is not a spot for Sanjay and his friends to try and peddle their wares when they don’t have the ability or skill to do it on their own without latching on to me via comment spam.

Here’s the screen-shot of their intrusion before I whacked it.

Actions like this make it easy to see exactly what kind of company and product they really have.

Additional LDAPS Requirements from Vista/W2K8

We have an ADAM instance that is protected by an SSL cert (LDAPS), and load-balanced behind a Cisco hardware device.  As a standard offering, we receive an SSL cert and a DNS alias for our “website”[1].  The DNS entry is similar to the following, with our public-facing name as an alias to the load-balancer:

C:\>nslookup adam.ad.test
Server:  UnKnown
Address:  192.168.2.1

Non-authoritative answer:
Name:    adam.ciscogss.ad.test
Address:  192.168.8.21
Aliases:  adam.ad.test

The SSL cert is also issued with the public-facing name of adam.ad.test.

This configuration functioned perfectly, for a while.  Eventually, we started having a few new application begin migrating to Windows Server 2008[2].  About this same time I also switched over to a Vista-based laptop as part of a pilot program within IT.

Connecting to our ADAM instance from either of these platforms resulted in a failure.  But, connecting from XP or W2K3 continued to work flawlessly.

This was a highly unexpected failure.  I had no problems connecting to any SSL-protected website from Vista or W2K8.  Any of those websites had certs and DNS entries that would be identical to our own setup for ADAM.  If IE on Vista could connect to an https website whose name is an alias, why couldn’t LDP on Vista do the same?

It turns out, Microsoft decided to tighten-up the requirements just for creating LDAPS connections, starting from the Vista codebase.  The problem is the certificate name didn’t match the DNS response.  After getting a new SSL cert for the public-facing name that included the load-balancer name as a Subject Alternative Name (SAN), the connections from Vista and W2K8 started working.

So, if you ever run into the same situation, ADAM (or AD) must be protected with an SSL cert that matches all the names in the DNS resolution path.

[1] Since it was a standard hosting offering, it was a little tricky at first to get our hosting team to understand our requirement for hosting the SSL port on 636, rather than 443.

[2] Yes, my company can be a little slow at moving to new platforms.  We didn’t have anyone try and authenticate against the ADAM instance from Vista or W2K8 until about July 2009.

Computers in space

If you want a fun, interesting read about the early days of computing, and how the requirements for manned-spaceflight helped push the state-of-the-art, you can find an insightful essay at http://history.nasa.gov/computers/contents.html.

Update on Exchange 2010 and AdminSDHolder

The Microsoft Exchange Team recently blogged on the ACEs being applied by Exchange 2010, that I discussed previously.

“[A]s some have correctly pointed out, that enables an elevation of privilege scenario that is unacceptable in any environment.  Microsoft agrees with this assessment and concurs that Exchange 2010 cannot ship with the permissions assigned to the AdminSDHolder role that allow for Active Directory forest privilege elevation.”

It’s great to see, especially this close to the planned release, that Microsoft realized what a critical controls issue this would have been, and is correcting the problem.

Bravo!

Exchange 2010 RC1 and AdminSDHolder

 

This post discusses Release Candidate software which may or may not reflect the final shipping version.

With the recent release of Exchange 2010 RC1, I threw it into a new sandbox to see what its schema and Forest/Domain Prep steps were like.

A picture is worth a thousand words.

After the PrepareAD steps have finished, AdminSDHolder has several new ACEs added to it.  I’ve highlighted the most inappropriate ACE: Write Property for member, granted to the new Exchange Windows Permissions group.  This makes it possible for an Exchange Organization Administrator to elevate themselves to Enterprise Administrator with two actions (left as a simple exercise to the reader).

AdminSDHolder exists to protect the critical security groups, such as Enterprise Admins, from inadvertent  or accidental tampering by periodically setting the ACEs on those objects to known good values.  Since those values were originally defined by the authors of the AD code, they probably know a thing or two about what values are needed to protect AD.  With the new ACE on AdminSDHolder, AD itself now dutifully ensures that the new Exchange group can manage group membership for the Enterprise Admins group (along with Domain Admins, Account Operators and all other groups that were supposed to be “protected”).

Beyond AdminSDHolder, PrepareAD also throws down identical ACEs on the domain head, including ACEs like Write DACL inherited to all objects.  But from a controls perspective, none are needed beyond the initial Write Property for member.

If your organization has any rules for separation of duties between Exchange Admins and Enterprise Admins, the ACEs introduced by Exchange 2010 RC1 make that very difficult to enforce, if not impossible.

Unencrypting GSS-API Encrypted Payloads

 

In an earlier post I lamented the fact that Netmon couldn’t automatically use a server’s own private key to be able to decode SSL packets.  When working on something else, I ran across this post that details how to disable LDAP encryption.  I don’t know if it disables the encryption for NetLogonr or not, but thought someone may find the procedure useful.

My Vista SP2 Experience

Install went rather well, but my Dell Latitude D620 experienced one issue.  The Intel Wireless device disappeared from device manager after the install completed, and the WiFi indicator light was not lit.  Reboot into BIOS setup, and verified the device was still enabled – which it was.  I ended up setting the WiFi catcher setting back to basic mode, which apparently reset the device enough that the WiFi indicator light was lit for the next reboot and my wireless was functional again.  Otherwise the install went smoothly.  Now it’s on to my W2K8 dev servers.

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.