The Free Loder

PowerShell DirSync Sample

2012-01-27T17:54:00.001-05:00

Continuing with the PoC setup for the SQL Server MA, I want the flexibility to load the SQL data from either the authoritative text-file, or from a separate AD environment. This will provide me the ability to test the MA in Dev and QA environments that are not as active as Production. To do that, I want DirSync data from a source domain to use to populate the table.

Microsoft’s DirSync documentation has a sample in C++. 400+ lines of code! And a very low percentage of the code volume is directly related to the search. Yuck. However, with some more Googling one can find that Brandon has a System.DirectoryServices.Protocols sample for PowerShell and the Israel Platforms PFE Team has a DirSync sample for C#. Finally SANS had a nice overview on handling the Byte in PowerShell, which the DirSync cookie uses.

All the ingredients are assembled. Combine and bake at 400° for 20 minutes and you get:

[Reflection.Assembly]::LoadWithPartialName("System.DirectoryServices.Protocols") | Out-Null

If (Test-Path .\cookie.bin –PathType leaf) {
    [byte[]] $Cookie = Get-Content -Encoding byte –Path .\cookie.bin
} else {
    $Cookie = $null
}

$RootDSE = [ADSI]"LDAP://RootDSE"
$LDAPConnection = New-Object System.DirectoryServices.Protocols.LDAPConnection($RootDSE.dnsHostName)
$Request = New-Object System.DirectoryServices.Protocols.SearchRequest($RootDSE.defaultNamingContext, "(objectclass=*)", "Subtree", $null)
$DirSyncRC = New-Object System.DirectoryServices.Protocols.DirSyncRequestControl($Cookie, [System.DirectoryServices.Protocols.DirectorySynchronizationOptions]::IncrementalValues, [System.Int32]::MaxValue)
$Request.Controls.Add($DirSyncRC) | Out-Null

$Response = $LDAPConnection.SendRequest($Request)

$MoreData = $true

while ($MoreData) {

    $Response.Entries | ForEach-Object {
        write-host $_.distinguishedName
    }

    ForEach ($Control in $Response.Controls) {
        If ($Control.GetType().Name -eq "DirSyncResponseControl") {
            $Cookie = $Control.Cookie
            $MoreData = $Control.MoreData
        }
    }
    $DirSyncRC.Cookie = $Cookie
    $Response = $LDAPConnection.SendRequest($Request)
}

Set-Content -Value $Cookie -Encoding byte –Path .\cookie.bin

There you have it. PowerShell DirSync in 27 lines of code!

FIM SQL Server MA (or PowerShell for SQL Table-Valued Parameters)

2012-01-26T18:15:00.001-05:00

Working on a Proof of Concept for FIM has been a refreshing visit to some of my old haunting grounds. Long before AD existed (or even NT) my first real job was for a database consulting company. It no longer exists, but its legacy can be found at www.noetix.com; and some of the people I knew back then are still there.

The FIM PoC begins with a text-based authoritative data source with no natural key. The FIM text-based MAs require a key, so I could not use those MAs and still support user account renames. So I decided to import the data into a SQL Server table with an Identity column and use the SQL Server MA. This decision has brought me a fair amount of SQL work that I have not done for years.

The first fun task was generating the delta view. I opted to follow the trigger approach, but wanted it to act more like Active Directory DirSync where one can retrieve the deltas based on a cookie being held and presented, but the older deltas still exist. So I created a timestamp-based view of the delta table at MA runtime specific to my particular FIM instance. The view will present all the deltas from the last provided timestamp plus a 5 minute overlap to handle the Kerberos-allowed time skew. This approach also allows a parallel FIM instance to receive its own deltas without impact to each other by simply creating a differently-name view specific to that instance.

Then I started working on multi-valued attributes. Per standard normalization rules for SQL, one ends up with a second table linking the primary object table Identity column to the multivalued attribute name and a single value. To add a second value to the attribute the table needs another row with the same Identity foreign key, same attribute name and the second single value.

FIM’s granularity for SQL deltas is limited to indicating the object as a whole has changed. It has no granularity for indicating attribute deltas like DirSync can, so any insert or delete into the multi-valued table triggers a delta of the whole object. This matches up well with the text-based source as all attributes (single and multi) are encoded into one row in the file. There is no easy way to know what has changed in the source data when it is received, so I simply need to make sure the SQL data exactly matches the newly received row from the authoritative data source. Put into practice this means all of the single-valued attributes must be rewritten, all the existing multi-valued attributes must be deleted and the new multi-valued attributes must be inserted.

I was brought up with the stored-procedure methodology for interacting with any database, so my goal was to develop a stored procedure that I could call from PowerShell to take care of the attribute updates. I split this into two stored procedures: one for the single-valued attributes, and one for the multi-valued attributes that I could iterate over for each multi-valued attribute in the source feed. The multi-valued stored procedure causes difficulty in the handling of the one delete and “n” number of inserts. You can’t put that into one stored procedure and support an unknown number of multi-value attribute inserts. So either it has to be broken into two stored procedures (execute the delete stored procedure followed by n executions of the insert stored procedure), or find a way to get the single stored procedure to recognize an array for the inserts.

The multiple stored procedures didn’t sound elegant, and I haven’t worked on SQL Server for a while, so I spent a little time searching and fairly quickly found Table-Valued Parameters and a great blog entry from Erland Sommarskog, SQL Server MVP. One of the nice benefits of FIM not being cross-platform is its requirement of SQL 2008 and the ability for me to now use other new SQL 2008 features.

Begin by creating a User Defined Table Type:

CREATE TYPE [dbo].[multivalue_list] AS TABLE(
[attributevalue] [nvarchar](1024) NOT NULL
)

Create a stored procedure that uses that type[1]:

CREATE PROCEDURE
    [dbo].[import_people_multivaluesdata]
          @p_cn varchar(64)
        , @p_attributename varchar(64)
        , @p_multivalue_list multivalue_list READONLY

AS
BEGIN
    -- SET NOCOUNT ON added to prevent extra result sets from
    -- interfering with SELECT statements.
    SET NOCOUNT ON;

    -- Insert statements for procedure here
    DELETE FROM
        people_multivalues
    WHERE
            AttributeName = @p_attributename
        and ObjectID IN (
            SELECT
                ObjectID
            FROM
                objects
            WHERE
                cn = @p_cn
            )

    INSERT INTO
        people_multivalues
    SELECT
          o.ObjectID
        , @p_attributename
        , mvl.attributevalue
    FROM
          objects o
        , @p_multivalue_list mvl
    WHERE
        o.cn = @p_cn

    SELECT
        COUNT(m.objectid) as row_count
    FROM
        objects o
            JOIN
        people_multivalues m
            ON
                o.ObjectID = m.ObjectID
    WHERE
            o.cn = @p_cn
        and m.AttributeName = @p_attributename
END

There are two important things to note in this procedure. The first is the use of the READONLY directive on the input table parameter. The second is the FROM clause for the INSERT statement having no JOIN clause. The incoming table only has the values for multi-valued attribute, so there is nothing on which to join. This results in the Cartesian product between the two, resulting in one row being inserted for each row in the input table parameter – exactly the goal!

Calling this procedure from T-SQL is fairly straight forward:

declare @mylist multivalue_list
insert @mylist(attributevalue) values ('val1'), ('val2')
exec import_people_multivaluesdata @p_cn = 'cn1', @p_attributename='multiattr', @p_multivalue_list = @mylist

Calling this from PowerShell requires a bit more setup. Mr. Sommarskog’s sample for ADO.Net (really C# SQLClient) can be translated into PowerShell as follows (switching from int to VarChar, and using our above stored procedure):

$products = "A", "B", "C"

$product_list = New-Object 'System.Collections.Generic.List[Microsoft.SqlServer.Server.SqlDataRecord]'

$tvp_definition = New-Object Microsoft.SqlServer.Server.SqlMetaData ("attributevalue", "VarChar", 1024)

ForEach ($product in $products) {
    $rec = new-object Microsoft.SqlServer.Server.SqlDataRecord($tvp_definition)
    $rec.SetSQLString(0, $product)
    $product_list.Add($rec)
}

$cmd.CommandType = CommandType.StoredProcedure
$cmd.CommandText = "dbo.import_people_multivaluesdata"

$cmd.Parameters.AddWithValue("@p_cn", "cn1") | Out-Null
$cmd.Parameters.AddWithValue("@p_attributename", "multiattr") | Out-Null
$cmd.Parameters.Add("@p_multivalue_list", [System.Data.SqlDbType]::structured) | Out-Null
$cmd.Parameters["@p_multivalue_list"].TypeName = "multivalue_list"
$cmd.Parameters["@p_multivalue_list"].Value = $product_list

$ReturnRowCount = $cmd.ExecuteScalar()

And there you have it. With one call to a stored procedure, all current multi-value attribute entries for a specific attribute will be deleted and completely replaced with the new list of values and is scalable to any number of entries in the list.

[1] You can tell the difference between my own SQL code for the procedure and the GUI-generated code for the UDT. This is how I was taught to write SQL code. I see very few other samples that follow the same layout. However, this is the only layout that gives you complete control of the ordering of table names or column names where you don’t have to worry about forgetting to have correct punctuation. All the column names in the select statement are nicely lined up, and you can easily verify all subsequent columns begin with a comma.

Administrator Locked Out of FIM Portal

2011-12-16T20:27:00.001-05:00

I’ve been coming up to speed on MIIS/ILM/FIM lately reading the documentation and walking through the evaluation guides in a small lab forest. I was walking through the FIM 2010 procedure Introduction to Publishing To Active Directory from Two Authoritative Data Sources using FIM 2010 R2. I had completed the main sync of HR into FIM and back to the Metaverse. When I switched back to the portal to check on the results I was greeted with an error screen.

I’m not sure what caused the problem. I didn’t have a backup to roll back to, and I didn’t want to give up and just reinstall. From experience I know that you seldom learn more about a program than when it’s broken. So I dove in to the problem.

I know FIM is mostly a large SQL application. I understand the sync database pretty well. It has two main tables. The mms_metaverse table stores each object in a row and each attribute in a column. This allows for indexing the attributes for fast joins and searching the metaverse. The mms_connectorspace is more opaque. The data from the connector space is stored as XML blobs in the hologram.

My first glance at the FIMService database showed me it didn’t look anything like the sync database.

To get started I profiled my attempt to open the portal. You see a call retrieve the default page from SharePoint, then you see the call to figure out who I am.

This is a stored procedure call to GetUserFromSecurityIdentifier where the parameter appears to be my SID in binary form.

Since SQL Server Profiler doesn’t show the return value of the query, I ran that query myself.

Sure enough, no rows returned. Looking at the stored procedure, it references the tables UserSecurityIdentifiers and Objects. UserSecurityIdentifiers was completely empty. UserSecurityIdentifiers is a simple table with only two columns: UserObjectKey and SecurityIdentifier.

There’s also a stored procedure called GetUserFromName. When I ran that, it returned my name, so I was pretty sure I was just missing the row that tied my AD SID to the admin user in FIM.

To find my admin user in FIM I ran a query against the Objects table to find the FIM builtin administrator account '7FB2B853-24F0-4498-9534-4E10589723C4'

For my instance it returned a value of 2340.

I issued one more query to insert my SID into the UserSecurityIdentifiers table.

The value successfully added. I opened the portal and was treated to the normal administrative view!

I still don’t know what I changed to cause the SID to be deleted, but now at least I know how to get back in without a backup. Perhaps some more testing in the future will reveal a repeatable pattern that causes the lockout.

Access Denied when backing up WINS on Windows Server 2008

2011-07-18T18:06:00.000-04:00

As part of switching our services over to Windows Server 2008, we began migrating WINS and our management scripts for WINS. Our existing Windows Server 2003 based backup script did not work. It was returning an access denied error.

Firing up Process Monitor produced this report.

I couldn’t image how a windows service didn’t have permission to write to the filesystem.

Looking at the properties of the Process Monitor event shows this detail.

The user wasn’t NT Authority\System like I had expected. Instead it was NT Authority\Local Service. A search for NT Authority\Local Service and WINS produced KB Article 943514. The article only references moving the database from its default location, but it also applies to backing up the database to another folder. The access denied error is resolved by issuing a command like

icacls d:\backupWINS /grant "NT SERVICE\WINS:(OI)(CI)F"

Obviously this grants the WINS service full control of the d:\backupWINS folder so that it now has permissions to create its backup files. With that in place, no more errors were encountered.

PowerShell example for LdapSessionOptions.VerifyServerCertificate

2011-03-21T21:39:00.001-04:00

I’ve started switching most of my management scripts over to PowerShell. I previously had written a small C# command-line tool that would display the certificate expiration date of a Domain Controller’s LDAPS certificate. This utility was based on Joe Kaplan’s sample. As this utility was called as part of a much larger and more complex VBScript it only made sense to incorporate this functionality directly into PowerShell as well. However, figuring out how to get PowerShell to deal with the VerifyServerCertificateCallback object was a more complex an undertaking than I had anticipated, and there were several times I almost gave up and kept the certificate date check as an external utility. However, I did eventually figure it out and thought I’d share since there are no specific examples anywhere and few examples about PowerShell and callbacks in general.

Within the .NET Framework, System.DirectoryServices.Protocols provides comparatively raw access to the LDAP APIs. In Joe’s example, the VerifyServerCertificate property is assigned to a new VerifyServerCertificateCallback object, which itself is a function that returns either True or False based on whatever logic one wants to employ.

Most of the examples I found centered on web-server SSL certificates and ServerCertificateValidationCallback and were based on either C# which has no issues with callbacks, like Joe’s, or PowerShell v1 which had to do lots of unnatural things to use the callback.

It turns out there are two important items to know about callbacks and PowerShell v2. First, callbacks are implemented as a scriptblock. Second, access to the callback parameters are provided via the args array.

Add-Type -AssemblyName System.DirectoryServices.Protocols
$LDAPId = New-Object System.DirectoryServices.Protocols.LdapDirectoryIdentifier(($DC + ":636"), $true, $false)
$LDAPConnection = New-Object System.DirectoryServices.Protocols.LdapConnection($LDAPId)
$LDAPConnection.Credential = New-Object System.Net.NetworkCredential("", "")
$LDAPConnection.AuthType = [system.directoryservices.protocols.authtype]::anonymous
$LDAPConnection.SessionOptions.SecureSocketLayer = $true
$LDAPConnection.SessionOptions.VerifyServerCertificate = {
    $MyCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $args[1]
    $DCCertDate = $MyCert.NotAfter
    $true
}
Try {
    $LDAPConnection.Bind()
} Catch {
    $DCCertDate = "No Certificate Found"
}

During execution, when the Bind method is called, the scriptblock attached to the VerifyServerCertificate property is called. The LdapConnection parameter for the VerifyServerCertificateCallback delegate is contained in args[0] and the X509Certificate in args[1]. In this particular example I use the callback certificate to create a new certificate object, store the expiration date and return true, which allows the connection to succeed.

Execute PowerShell Scripts with a Restricted Execution Policy

2010-05-25T21:47:00.001-04:00

By default, PowerShell will default to an execution policy of Restricted. Hopefully this is not a surprise to anyone. However, it is possible to execute scripts under this policy. Simply start the shell using the ExecutionPolicy parameter.

For example, in our server loads, we need to prompt for an administrative password during the post-install process. Previously, in W2K3, we were able to use the ScriptPW object to mask the input. The object no longer exists in W2K8, so a different solution was needed. Powershell provides the Read-Host cmdlet, which includes the AsSecureString parameter. Using that cmdlet, I created a simple script that would prompt for the password.

I then needed to run the script automatically, but didn’t want to change the default execution policy. To solve this, one can specify a one-time execution policy when starting the shell.

powershell -ExecutionPolicy RemoteSigned –File c:\postinstall\password.ps1

Happy 10th PromoDay .com

2010-04-12T20:53:00.001-04:00

My forest[1] celebrated the ten-year anniversary of the initial promotion today. We had upgraded from an NT4 multi-master configuration, so this was a new promotion to become the empty root. The account domains were slowly upgraded over the next year. Technically, the domain services as a whole are more than 10 years old, but the official NT4 dates are lost to the sands of time.

c:\>adfind -config -f name="Enterprise Configuration" whencreated -alldc

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

Using server: xxxx.xxxx.com:389
Directory: Windows Server 2003
Base DN: CN=Configuration,DC=xxxx,DC=com

dn:CN=Enterprise Configuration,CN=Partitions,CN=Configuration,DC=xxxx,DC=com
>whenCreated: 2000/04/12-19:25:22 Eastern Daylight Time

1 Objects returned

We held a party for it today, and even got a “PromoDay” cake.

[1] Not technically “my forest”. It does belong to the widget company for which I work, and I didn’t even work for them 10 years ago, and had nothing to do with its creation. joe was responsible for most of it [2]. These days there are 5 EAs with operational responsibility, and me with engineering responsibility who can likely continue to call it “ours”.

[2] There are a lot of good stories about the early days of our AD. This event brought out a few of them from ensuring joe didn’t promote the forest as joe.com to the buddy builds that were delivered almost daily as we pushed the scalability limits of Windows 2000 beyond what Microsoft had yet seen, but they’re joe’s to tell, not mine. Go read about them if you want.

User Account Control (UAC) and NSUpdate

2010-01-19T21:03:00.001-05:00

At work, I run my Vista SP2 system as a standard user with UAC turned on. For the most part, UAC doesn’t cause me any problems in my day-to-day duties, except for one item. Our DNS infrastructure runs on a BIND variant. As such, nsupdate.exe is a common command-line support tool. Similar to most other remote service management tools, the tool has no local security requirements. However, attempting to run nsupdate on Vista creates an elevation prompt. Using Windows Explorer, one can verify the executable is marked with the UAC shield.

However, only nsupdate.exe is marked – none of the other BIND tools are marked. Additionally, I found that renaming the file to something like nsupdat2.exe caused UAC to no longer prompt for elevation.

It turns out, there’s logic in UAC for elevating based on filename, regardless of local security requirements. This allows update installers to be elevated appropriately. However, nsupdate.exe is an innocent victim of a flawed heuristic detection pattern, like a false-positive from an AV signature.

To prevent UAC from forcing elevation of a process that doesn’t require it, this automatic prompting due to Installer Detection, can be turned off. http://technet.microsoft.com/en-us/library/cc709628(WS.10).aspx provides an overview of the feature and its possible configurations. In local security policy, navigate to Local Policies, Security Options and set User Account Control: Detect application installations and prompt for elevation to Disabled. When this policy is enabled, which is the default, any filename which contains “update” will trigger elevation. When disabled, this detection is turned off, and attempting to use nsupdate.exe no longer causes an elevation prompt. I see this as a much better solution than renaming the file. Now I can use nsupdate.exe as a standard user.

Comment Spam from Paramount Defenses

2009-10-21T21:10:00.001-04:00

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

2009-09-29T21:26:00.001-04:00

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

2009-09-29T20:41:00.001-04:00

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

2009-09-23T22:17:00.001-04:00

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

2009-08-24T21:52:00.001-04:00

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

2009-06-29T21:29:00.001-04:00

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

2009-05-06T23:06:00.001-04:00

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

2009-04-26T22:15:00.001-04:00

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

Who told AD what OS I’m running?

2009-04-22T23:29:00.000-04:00

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

2009-04-22T21:23:00.001-04:00

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!

2009-04-22T20:59:00.001-04:00

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.