none
Problem with Active Directory patch MS15-96?

    Question

  • Hi,
    I have a problem with patch MS15-96. When this patch has been installed on a domain controller the following code doesn’t work anymore. Instead of creating a correct computer object it creates a computer object with these faulty properties( It is still possible to create correct computer objects with ADUC).

    Faulty properties:
    primaryGroupID = 513 (Group_Rid_Users)
    sAMAccountType = 805306368 (Normal_User_account)

    The properties should be:
    primaryGroupID = 515 (Group_Rid_Computers)
    sAMAccountType = 805306369 (Machine_account)

    ---------------Start Code----------------------------
    Imports System.DirectoryServices
    Public Class Form1
        Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
            Dim de01 As New DirectoryEntry("LDAP://patchedDC.domain.org/OU=AtestOU,DC=domain,DC=org")
            Dim newComputer As DirectoryEntry = de01.Children.Add("CN=computer1", "computer")
            newComputer.CommitChanges()
        End Sub
    End Class
    ---------------End Code----------------------------

    Has anyone else noticed this? Is it a Bug?
    Saturday, October 24, 2015 12:46 PM

Answers

  • Hi,

    Seems like intended behavior to me.

    This security update prevents non-administrators from changing the value of the UserAccountControl attribute on an existing user or computer object. Any attempt to change the UserAccountControl value for an existing object by a non-administrative account will result in failure.

    The most frequently affected operation occurs when applications interactively or programmatically create objects in Active Directory as user accounts and then convert them to computer accounts, or vice-versa, by changing the UserAccountControl value.

    One mitigation is to create user or computer objects that have the intended UserAccountControl value when the object is created. For example, objects that are intended to be computer accounts should have a UserAccountControlvalue that contains WORKSTATION_TRUST_ACCOUNT during object creation.

    Quoted from the KB article below:

    MS15-096: Vulnerability in Active Directory service could allow denial of service: September 8, 2015

    https://support.microsoft.com/en-us/kb/3072595

    Best Regards,

    Amy


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, October 27, 2015 1:15 PM
    Moderator

All replies

  • Hi,

    Seems like intended behavior to me.

    This security update prevents non-administrators from changing the value of the UserAccountControl attribute on an existing user or computer object. Any attempt to change the UserAccountControl value for an existing object by a non-administrative account will result in failure.

    The most frequently affected operation occurs when applications interactively or programmatically create objects in Active Directory as user accounts and then convert them to computer accounts, or vice-versa, by changing the UserAccountControl value.

    One mitigation is to create user or computer objects that have the intended UserAccountControl value when the object is created. For example, objects that are intended to be computer accounts should have a UserAccountControlvalue that contains WORKSTATION_TRUST_ACCOUNT during object creation.

    Quoted from the KB article below:

    MS15-096: Vulnerability in Active Directory service could allow denial of service: September 8, 2015

    https://support.microsoft.com/en-us/kb/3072595

    Best Regards,

    Amy


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, October 27, 2015 1:15 PM
    Moderator
  • Are you sure that is the code that creates the object? When a computer object is created in AD, the system automatically assigns the correct default values for sAMAccountType and primaryGroupID. I have never seen code that modifies these attributes (except in the rare cases where the primary group is later changed).

    Richard Mueller - MVP Directory Services

    Tuesday, October 27, 2015 1:33 PM