Blog - Title

April, 2009

  • “The LastLogonTimeStamp Attribute” – “What it was designed for and how it works”

    Warren here. In Windows Server 2003 we introduced the lastLogontimeStamp attribute. Administrators can use the lastLogontimeStamp attribute to determine if a user or computer account has recently logged onto the domain. Using this information administrators can then review the accounts identified and determine if they are still needed and take appropriate action.

    Intended Use

    It is important to note that the intended purpose of the lastLogontimeStamp attribute to help identify inactive computer and user accounts. The lastLogon attribute is not designed to provide real time logon information. With default settings in place the lastLogontimeStamp will be 9-14 days behind the current date.

    If you are looking for more “real-time” logon tracking you will need to query the Security Event log on your DC’s for the desired logon events i.e. 528 –Windows XP\2003 and earlier or 4624 Windows Vista\2008 . See this blog post by Eric Fitzgerald for more info. (I think he knows something about auditing)

    IMO your best bet for near real-time data is to use an event log collection service to gather all domain controller security event logs to a centralized database. You can then query a single database for the desired logon events. Microsoft’s solution for security event log collection is Audit Collection Services. There are many 3rd party solutions as well.

    How it worked in Windows 2000

    Prior to Windows Server 2003 administrators had to query the lastLogon attribute to determine the most recent logon of user or computer account. This process was time consuming as the lastLogon attribute is updated only on the DC that validates the logon request. The lastLogon attribute is not replicated. So in the past to determine the most recent logon of a user or computer account the lastLogon attribute had to be queried on all domain controllers (at least in concept) and then the most recent date for lastLogon had to be determined from all the results returned. In Windows 2003 and higher lastLogon is still has the same behavior. It is updated only on the validating DC and is not replicated.

    How it works in Windows Server 2003 and later

    In contrast the lastLogontimeStamp attribute is replicated so all DC's have the same value for the attribute (after replication convergence). Therefore you can query a single DC to find all the users or all the computers that have not logged in within a certain time.

    Requirements

    Your Windows domain must be at Windows 2003 Domain Functional Level for updates to the llastLogontimeStamp to occur.

    Logon types and that will trigger an update to the lastLogontimeStamp attribute.

    The lastLogontimeStamp attribute is not updated with all logon types or at every logon. The good news is that the logon types that admins usually care about will update the attribute and often enough to accomplish its task of identifying inactive accounts.

    Interactive, Network, and Service logons will update the lastLogontimeStamp. So if a user logs on interactively, browses a network share, access the email server, runs an LDAP query etc… the lastLogontimeStamp attribute will updated if the right condition is met. (The conditions are discussed below in the section Update and Replication of lastLogontimeStamp.

    As of Windows 2003 SP1 these logon types will NOT update lastLogontimeStamp

    • Certificate mapping through Microsoft Internet Information Services (IIS).
    • Microsoft .NET Passport mapping through IIS.

    [Update June 19, 2009 - removed one item from the list above that is under debate in a repro currently. Will update when we have more word] 

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

    Update and Replication of lastLogontimeStamp

    First become acquainted with the ms-DS-Logon-Time-Sync-Interval attribute. It is an attribute of the domain NC and controls the granularity (in days) with which the lastLogontimeStamp attribute is updated. The default value is 14 and is set in code. Meaning that if you look at this attribute in ADSIEDIT.MSC and you see it as "Not Set" don't be alarmed. This just means the system is using the default value of 14.

    The lastLogontimeStamp attribute is not updated every time a user or computer logs on to the domain. The decision to update the value is based on the current date minus the value of the (ms-DS-Logon-Time-Sync-Interval attribute minus a random percentage of 5). If the result is equal to or greater than lastLogontimeStamp the attribute is updated. There are no special considerations for replication of lastLogontimeStamp. If the attribute is updated it is replicated like any other attribute update. This is not urgent replication

    Walkthrough of a lastLogontimeStampUpdate update

    1. (Assuming the value of the ms-DS-Logon-Time-Sync-Interval is at the default of 14)

    2. User logs on to the domain

    3. The lastLogontimeStamp attribute value of the user is retrieved

    4. 14 - (Random percentage of 5) = X

    5. Current date - value of lastLogontimeStamp = Y

    6. X ≤ Y - update lastLognTimeStamp

    7. X > Y - do not update lastLogontimeStamp

    Why the Randomization?

    This randomization is done to prevent an update of the lastLogontimeStamp attribute from many accounts at the same time causing a high replication load on the DC's. Remember the purpose of the lastLogontimeStamp attribute is locate inactive accounts not provide real-time logon information.

    Controlling the update frequency of lastLogontimeStamp.

    It is possible to change the frequency of updates to the lastLogonTime stamp or turn it off completely if desired. If you need a different time interval you will need to adjust the value of the msDS-LogonTimeSyncInterval attribute to a value between 5-100,000. Yes that’s right: the max value is 100,000 days… Or if you prefer ~280 years... And the max value was set in code not in the schema. (I guess the dev was counting on medical science to solve that pesky aging problem.)

    In my experience the default settings can accommodate almost anyone and there is no need to change the update interval. Most customers I have talked to start considering accounts potentially inactive at the 30 day or higher mark of inactivity.

    Note: If the msDS-LogonTimeSyncInterval is less than 5 days, the randomization is not put into effect.

    How do I turn this thing off?

    If you want to disable the lastLogontimeStamp feature set the msDS-LogonTimeSyncInterval attribute to 0.

    I personally have never spoken with anyone that really had a business need to change how often lastLogontimeStamp needs to be updated. Once it was explained how the update process works and it was proven that the attribute is current and replicated to all DC’s that was all that was needed. If really think you need a more recent timestamp than 9-14 days for inactive account detection I suggest you make small changes and monitor DC workloads. This is especially true in large environments.

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

    Clearing up the confusion - Verifying that LastLogontimeStamp is in sync across all DCs in the domain.

    Many times customers will be concerned about what their tools are displaying to them (usually a very old date) as the lastLogontimeStamp of a user compared to what they know to be a more accurate date. This is almost always due to the admin using a tool that queries the lastLogon attribute instead of the lastLogontimeStamp attribute.

    For example acctinfo.dll that is included with the Account Lockout tools will display the lastLogon attribute data not the lastLogontimeStamp data. In some cases the date the tool reports may be months or years out of date or display nothing at all. This is because they are querying the lastLogon attribute and the user they are looking up has either never been authenticated by the reference DC (in the case of null) or has not been authenticated by the reference DC in a very long time.

    How to tell if lastLogontimeStamp is in sync

    To verify if the lastLogonTime stamp is being updated and replicated as expected you can use repadmin.exe with the showattr switch. Some examples are given below. These examples are intended to demonstrate that lastLogontimeStamp is being updated within the window of 9-14 days and replicated to all DC’s in the domain. They are not an example of how to manage stale accounts.

    1. Using repadmin to check the value of lastLogontimeStamp on all DC's in a domain for one user:

    repadmin /showattr * (DN of the target user) /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

    Example:

    repadmin /showattr * CN=user1,OU=accounting,DC=domain,dc=com /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

    2. Using repadmin to dump the lastLogontimeStamp for all users in a domain including users that have no data in the lastLogontimeStamp attribute:

    repadmin /showattr * /subtree /filter:"(&(objectCategory=Person)(objectClass=user))" /attrs:lastLogontimeStamp >lastLogontimeStamp.txt

    3. Dump lastLogonTime stamp for users but only ones that have the attribute populated

    repadmin /showattr * dc=domain,dc=com /subtree /filter:"((&(lastLogontimeStamp=*)(objectCategory=Person)(objectClass=user)))" /attrs:lastLogontimeStamp > lastLogontimeStamp-2-22-2009.txt

    - Warren ‘For Once not DFSR’ Williams

  • How to configure the Windows Server 2008 CA Web Enrollment Proxy

    Hi all, Rob here again. I had a case recently where the customer wanted to have the Windows Server 2008 Certificate Authority website loaded on another machine.

    For those of you that do not know, you can install the Windows Server 2008 CA web site pages on an alternate server from the CA. One reason why you might deploy this configuration is if you currently have a Windows 2000 / Window Server 2003 Certification Authority and need to be able to deploy certificates to Windows Vista and Windows Server 2008 machines via the CA web site pages. Another reason might be because you want to offer certificate enrollment to Internet-based users but do not want to expose your Certification Authority to the Internet.

    While I was working with the customer I found quite a few different configurations that are possible with IIS7, but each configuration requires a different setup within Active Directory and IIS7.

    Getting started

    The first thing to be decided is which account will be used for the web application pool account.

    • Network Service.
    • A domain user account (also known as custom identity).

    The easier configuration is to leverage Network Service as the application pool account for the CertSrv web site. However, if you plan on bringing up more than one web server and use a network load balancer in front of the web servers your only option is to use a domain user account for the application pool identity.

    The second thing that needs to be decided is what type of delegation you require in the environment.

    I am not going to dig deeply into the differences between open and constrained delegation; you can view the Kerberos section of the AskDS blog. Basically, constrained delegation is more secure because you are limiting to what back end service the application is allowed to impersonate the user account to.

    Installing the Certification Authority website pages

    Alright, so you have made your decision on what type of delegation you want and what account you will be using for the Web Application Pool Identity. Let’s install the IIS components:

    1. Launch Server Manager (servermanager.msc).

    2. Click on the Add Roles link in the right hand pane.

    clip_image002

    Installation Figure 1 - Add Roles

    3. Check Active Directory Certificate Services and click the Next button.

    4. Uncheck Certification Authority and check Certification Authority Web Enrollment. You will see the pictured dialog box stating that IIS roles will need to be added, so click on the Add Required Role Services button, and then click the Next button.

    clip_image004

    Installation Figure 2 - Select Role Services

    5. You will then be asked to select the Enterprise Certification Authority that the web enrollment pages should use.

    6. Click the Browse button, and the Select Certification Authority dialog box will be shown listing all the Certification Authorities in the forest.

    7. Select the Certification Authority and click on the OK button, and click the Next button.

    clip_image006

    Installation Figure 3 - Select Certification Authority

    8. Next you will be taken to the list of Role Services for the Web Server (IIS).

    9. Add any other role services that you might need to support for the CA Web Enrollment web site like maybe enabling Basic Authentication keep in mind that Windows Integrated Authentication is selected by default.

    10. Then click the Next button.

    11. Lastly it will show you a confirmation screen before actually installing the web pages and IIS as shown below.

    clip_image008

    Installation Figure 4 - Confirm Installation Options

    The next sections are broken down first by what the IIS Application Pool Identity runs as and then what type of Kerberos delegation you require. You can skip to the section that is relevant to your environment.

    Setting up with Application Pool Identity set to Network Service

    This section will cover how to configure IIS and the Active Directory accounts to support Kerberos open delegation as well as constrained delegation when the application pool identity is setup for Network Service.

    Configuring for open delegation when using Network Service for AppPool Identity

    1. Open up Active Directory Users and Computers (DSA.MSC) and double click on the IIS Computer account.

    2. Click on the Delegation tab, and select Trust this computer for delegation to any service (Kerberos only).

    clip_image010

    Network Service Delegation 1 - Configure Computer for open delegation

    3. Then click OK.

    4. Next we need to open Internet Information Services (IIS) Manager snapin.

    5. Navigate to the CertSrv web application in the tree view, and double click on Authentication.

    6. You should see all the supported authentication types listed.

    7. Right click on Windows Authentication and select Enable if not already done.

    8. Right click on Windows Authentication and selected Advanced Settings…

    clip_image012

    Network Service Delegation 2 - Windows Authentication Advanced settings

    9. Check Enable Kernel-mode authentication, and click the OK button.

    clip_image014

    Network Service Delegation 3 - Enable Kernel-mode Authentication

    10. Reboot the IIS computer and you are ready to go.

    Configuring for constrained delegation when using Network Service for AppPool Identity

    If you need to support Basic Authentication on the website you will need to make sure that you configure constrained delegation with protocol transition. However, you will need to scroll down to section Configuring the web site to support Basic Authentication below for more steps required to support basic authentication.

    1. Open up Active Directory Users and Computers and find the IIS computer account.

    2. Double click on the IIS Computer account.

    3. Click on the Delegation tab and select Trust this computer for delegation to specified services only

    4. Once the above option selected, you need to make another choice of one of the following:

    a. Use Kerberos only (Kerberos constrained delegation).

    b. Use any authentication protocol (Kerberos constrained delegation with protocol transition).

    5. Click on the Add... button.

    6. You now have the Add Services dialog box, click on the Users or Computers… button.

    7. In the Select Users or Computers dialog, type in the Certification Authority computer account and click OK.

    8. Select the following services HOST and rpcss. Once they have been selected click the OK button.

    9. Once this is done it should look similar to the figure Network Service Delegation 4.

    clip_image016

    Network Service Delegation 4 - Configure Computer for constrained delegation

    10. Next we need to open Internet Information Services (IIS) Manager snapin

    11. Navigate to the CertSrv web application in the tree view, and double click on Authentication.

    12. You should see all the supported authentication types listed.

    13. Right click on Windows Authentication and select Enable if not already done.

    14. Right click on Windows Authentication and selected Advanced Settings…

    clip_image017

    Network Service Delegation 5 - Windows Authentication Advanced Settings

    15. Uncheck Enable Kernel-mode authentication, and click the OK button.

    clip_image019

    Network Service Delegation 6 - Disable Kernel-mode authentication

    16. Reboot the IIS computer and you are ready to go.

    Setting up with Application Pool Identity set to custom account

    This section will cover how to configure IIS and the Active Directory accounts to support Kerberos open delegation as well as constrained delegation when the application pool identity is setup for a custom account.

    Configuring the Application Pool identity custom account

    This section must be done whether you are using open or constrained delegation.

    1. Next we need to open Internet Information Services (IIS) Manager snapin

    2. Navigate to the Application Pools node in the tree view.

    3. Select DefaultAppPool right click and select Advanced Settings…

    clip_image021

    Custom Account Delegation 1 - Application Pool Advanced Settings

    4. Change the Identity on the Advanced Settings dialog box, which then brings up the Application Pool Identity dialog box. Click on the Set… button.

    5. In the Set Credentials dialog box, type in the domain user account to be used and password twice. Do not forget to type in the domain name. For example: FABRIKAM\IISKerbSvc

    6. Click OK

    7. Click OK

    8. Click OK

    clip_image023

    Custom Account Delegation 2 - Configure Custom account

    9. Open Active Directory Users and Computers snapin (dsa.msc) and find the domain account that the application pool was set to from step 5.

    10. Add this account the Windows Authorization Access Group.

    11. Click OK

    12. Exit Active Directory Users and Computers.

    clip_image025

    Custom Account Delegation 3 - Add Custom account to domain group

    13. Open Computer Management snapin (compmgmt.msc) and go to the local groups in the tree view.

    14. Add the account specified for the application pool identity to the IIS_IUSRS group

    clip_image027

    Custom Account Delegation 4 - Add Custom account to IIS_IUSRS

    15. Next we need to open Internet Information Services (IIS) Manager snapin

    16. Navigate to the CertSrv web application in the tree view, and double click on Authentication.

    17. You should see all the supported authentication types listed.

    18. Right click on Windows Authentication and select Enable if not already done.

    19. Right click on Windows Authentication and selected Advanced Settings…

    clip_image028

    Custom Account Delegation 5 - Windows Authentication Advanced Settings

    20. Check Enable Kernel-mode authentication, and click the OK button.

    clip_image029

    Custom Account Delegation 6 - Enable Kernel-mode authentication

    Configuring for open delegation when using custom account for AppPool Identity

    1. Open up Active Directory Users and Computers and double click on the IIS Computer account.

    2. Click on the Delegation tab, and select Trust this computer for delegation to any service (Kerberos only).

    clip_image010[1]

    Custom Account Delegation 7 - Configure Computer for open delegation

    3. Then click OK.

    4. Reboot the IIS computer and you are ready to go.

    Configuring for constrained delegation when using custom account for AppPool Identity

    If you need to support Basic Authentication on the website you will need to make sure that you configure constrained delegation with protocol transition. However, you will need to scroll down to the bottom of this blog for more steps required to support basic authentication.

    1. Open up Active Directory Users and Computers and find the IIS computer account.

    2. Double click on the IIS Computer account.

    3. Click on the Delegation tab and select Trust this computer for delegation to specified services only, and then select Use any authentication protocol.

    4. Click on the Add... button.

    5. You now have the Add Services dialog box, click on the Users or Computers… button.

    6. In the Select Users or Computers dialog, type in the Certification Authority computer account and click OK.

    7. Select the following services HOST and rpcss. Once they have been selected click the OK button.

    8. Once this is done it should look similar to the figure Custom Account Delegation 8.

    clip_image031

    Custom Account Delegation 8 - Configure Computer for constrained delegation

    9. Next we need to add a Service Principal Name to the Application Pool account. This is done by using the SetSPN.exe utility. If my web site name is the IIS computer name (FAB-RT-MEM1) and I am using the account of FABRIKAM\IISKerbSvc the following commands would be ran:

    SetSPN –A http/fab-rt-mem1 FABRIKAM\IISKerbSvc

    SetSPN –A http/fab-rt-mem1.fabrikam.com FABRIKAM\IISKerbSvc

    10. Find the Application Pool Identity account within Active Directory Users and Computers.

    11. Double click on the domain user account.

    12. Click on the Delegation tab and select Trust this computer for delegation to specified services only and then select Use any authentication protocol.

    13. Click on the Add... button.

    14. You now have the Add Services dialog box, click on the Users or Computers… button.

    15. In the Select Users or Computers dialog, type in the Certification Authority computer account and click OK.

    16. Select the following services HOST and rpcss. Once they have been selected click the OK button.

    17. Click on the Add... button.

    18. You now have the Add Services dialog box, click on the Users or Computers… button.

    19. In the Select Users or Computers dialog, type in the IIS Server computer account and click OK.

    20. Select the following services HOST. Once they have been selected click the OK button.

    21. Once this is done it should look similar to the figure Custom Account Delegation 9.

    clip_image033

    Custom Account Delegation 9 - Configure custom account for constrained delegation

    22. Next we need to open Internet Information Services (IIS) Manager snapin

    23. Navigate to the CertSrv web application in the tree view, and double click on Authentication.

    24. You should see all the supported authentication types listed.

    25. Right click on Windows Authentication and select Enable if not already done.

    26. Right click on Windows Authentication and selected Advanced Settings…

    clip_image034

    Custom Account Delegation 10 - Windows Authentication Advanced Settings

    27. Uncheck Enable Kernel-mode authentication, and click the OK button.

    clip_image035

    Custom Account Delegation 11 - Disable Kernel-mode authentication

    28. Reboot the IIS computer and you are ready to go.

    Configuring the web site to support Basic Authentication

    Alright, so you need to support basic authentication huh…. Well, before you do the below steps you will first want to make sure that you have followed one of the set of steps for configuring constrained delegation and selected the Use any authentication protocol when you setup delegation.

    1. Next we need to open Internet Information Services (IIS) Manager snapin

    2. Navigate to the CertSrv web application in the tree view, and double click on Authentication.

    3. You should see all the supported authentication types listed.

    4. Right click on Basic Authentication and select Enable if not already done.

    5. The next part we will need to edit one of the following config files on the file system.

    • %systemroot%\system32\certsrv\en-US\Web.config

    You are looking for the part that is in bold below.


    <authentication>
       <basicAuthentication enabled="true" realm="contoso.com" defaultLogonDomain="CONTOSO" logonMethod="Network" />
       <windowsAuthentication enabled="false" useKernelMode="false" />
    </authentication>

    Change it from logonMethod=”Network” to logonMethod=”ClearText”

    NOTE: You might not have the web.config file located here.

    • %systemroot%\system32\inetsrv\config\applicationHost.config

    You are looking for the part in bold below, and then looking for basicAuthentication.


    <location path="Default Web Site/CertSrv">
          <system.webServer>
              <handlers accessPolicy="Read, Script">
                  <clear />
                  <add name="ISAPI-dll" path="*.dll" verb="*" modules="IsapiModule" resourceType="File" requireAccess="Execute" allowPathInfo="true" />
            …
                  <add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
              </handlers>
              <security>
                  <authentication>
                      <windowsAuthentication enabled="false">
                          <providers>
                              <clear />
                              <add value="Negotiate" />
                              <add value="NTLM" />
                          </providers>
                      </windowsAuthentication>
                      <anonymousAuthentication enabled="false" logonMethod="Network"/>
                      <basicAuthentication enabled="true" logonMethod="Network" />
                  </authentication>
            …

    Change it from logonMethod=”Network” to logonMethod=”ClearText” for basicAuthentication section.

    6. Reboot the IIS computer and you are ready to go.

     

    The steps outlined in this blog are specifically for the CA website being loaded on Windows Server 2008 and will not translate properly to the configuration required for the website on Windows Server 2003.

    The changes made to IIS7 have been drastic, from the GUI to the underlying code, so I hope that you have found this blog interesting and helpful.

    - Rob Greene

  • SQL Bulk Insert - Access is Denied

    Hey all, Mark from DS again. I have found that numerous cases have been opened where Microsoft customers are upgrading from SQL 2000 to SQL 2005. After the upgrade they were attempting to run a bulk insert statement either in the Enterprise Manager or the Management Studio application and getting an “Access is denied” error message. Here is what my customer was running:

    DROP TABLE #In_File

    CREATE TABLE #In_File(In_Data varchar(2000))

    BULK INSERT #In_File FROM '\\contoso.com\DFSRoot\share\subfolder\log.txt' WITH (FIELDTERMINATOR='\0', ROWTERMINATOR='')

    This is the error message they were getting (sound familiar anyone?):

    Msg 4861, Level 16, State 1, Line 3

    Cannot bulk load because the file "\\contoso.com\ DFSRoot\share\subfolder\log.txt " could not be opened. Operating system error code 5(Access is denied.).

    This customer had used the same command in SQL 2000 without issues. Only after the upgrade to SQL 2005 did it start failing. Per the SQL 2005 Online Books this behavior has changed in SQL 2005:

    image

    This customer had SQL running on a two node cluster (active\passive) and was attempting to import the file that happened to be on another 2 node file cluster (active\passive). So here is how to set this up properly after upgrading to SQL 2005. I will start off with a cluster configuration but I will make notes regarding a single server setup as well.

    First I want to identify all the names that I will be using. With a cluster you have a SQL Virtual network resource that I will call SQL1; there are also cluster nodes called Node1 and Node2. The SQL service is set to use a domain user account called SQL-Service-Acct. The domain name is contoso.com.

    1) The Virtual Name (SQL1) needs to be set for Enable for Kerberos Authentication. To do this open the Cluster Administrator MMC and locate the SQL1 network name resource, right click it and select Take Offline. You have to take the resource offline to be able to enable the Kerberos authentication. Once it is offline right click the resource again and select Properties. On the Parameters tab check the box for Enable Kerberos Authentication then click Ok. Right click the resource and select Bring Online. This will create a computer account in Active Directory so make sure the account that you use to perform this action above also has the user right to Add workstations to the domain. The computer account will be created in the “Computers” container. We will need to configure Kerberos delegation on the SQL service account so proceed to the next step as this depends on what the domain functional mode is set to in your environment.

    Note: If you are not running SQL on a cluster you can skip step #1 of course.

    2) Before going any further we need to talk about configuring Kerberos delegation on either the SQL service account or any computer accounts. If the domain is running in Windows 2000 (mixed or native mode) Domain Functional mode you will see differences on how to set the delegation vs. in a Windows 2003 Domain Functional mode. If the domain is in 2000 mode then on a computer account you will need to go to the properties of the computer account and simply check the box for the Trust computer for delegation on the General tab. If the domain is in 2003 mode then you will see a Delegation tab on the computer properties. In this case you need to select the radio button by Trust this computer for delegation to any service (Kerberos only).

    3) Now we will talk about the SQL service account, SQL-Service-Acct. It needs SPN’s (Service Principal Name) registered on the account and also needs to be set for delegation. If the domain functional mode is set to Windows 2000 then find the account in Active Directory Users and Computer MMC, right click select Properties and go to the Account tab. In the Account options scroll down and check the box for Account is trusted for delegation. If you do not see the Delegation tab that means that you have not added the SPN on the account. This must be done first before you will see the delegation tab. Make sure the box for Account is sensitive and cannot be delegated is NOT checked which is found on the Account tab under account options. The GUI will allow you to check both. If your domain is running in 2003 mode then you will have to go to the Delegation tab and make the same change as a computer account to enable the delegation but you first have to register the SPN’s on the SQL service account before the delegation tab will be available! You will need to go ahead and go to the next step then come back to enable the delegation.

    4) To register the SPN’s and the SPN’s to register on the SQL service account you will need to use the utility called setspn.exe. It can be downloaded here or by installing the Resource Kit tools. The SPN’s needed to be registered are as follows:

    Setspn –A MSSQLSvc/NetbiosNameOfSQLVirtualName SQLServiceAccountName

    Setspn –A MSSQLSvc/NetbiosNameOfSQLVirtualName:1433 SQLServiceAccountName

    Setspn –A MSSQLSvc/FullDNSNameofSQLVirtualName SQLServiceAccountName

    Setspn –A MSSQLSvc/ FullDNSNameofSQLVirtualName:1433 SQLServiceAccountName

    NOTE: The SPN’s that have the trailing port number are absolutely required. The SPN’s without the port number are optional. Also please note that if the instance is running on a different port number than the default 1433 then simply change the port number in the syntax.

    So in my case my SQL Virtual network name is SQL1 and the service account is SQL-Service-Acct so here is what I would run:

    Setspn –A MSSQLSvc/SQL1. contoso.com SQL-Service-Acct

    Setspn –A MSSQLSvc/SQL1. contoso.com:1433 SQL-Service-Acct

    Setspn –A MSSQLSvc/SQL1 SQL-Service-Acct

    Setspn –A MSSQLSvc/SQL1:1433 SQL-Service-Acct

    To verify that you have entered them correctly you can run the following command to list out what SPN’s are registered on the account:

    Setspn –L SQL-Service-Acct

    If you are not using the default port that SQL uses of 1433 then you need to change the syntax to reflect the port that you are using when adding the SPN’s.

    Note: If you are not running a cluster then you need to add the SPN’s using the server name that SQL is running on instead of the SQL Virtual name. Example:

    Setspn –A MSSQLSvc/SQLServer.contoso.com CONTOSO\SQL-Service-Acct

    5) Okay, moving right along now we should have the SQL Virtual name enabled for Kerberos and trusted for delegation, the SPN’s registered on the SQL service account and it is set for delegation. The next thing we need to do is make sure the SQL service account has a couple of userrights in the local security policy. Open gpedit.msc from the Start – Run and drill down to the following:

    Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

    Add the SQL-Service-Acct to the following policies:

    • Act as part of the operating system
    • Impersonate a client after authentication

    No need to run gpupdate as we are going to reboot here in a minute. Remember to modify the user rights assignments on both of the cluster nodes!

    6) Next find the actual machine accounts in Active Directory for the cluster nodes, node1 and node2. Set the computer accounts to be trusted for delegation as we did in step #2 for the SQL Virtual name. Once that is done reboot one of the nodes then once it is back up reboot the other node.

    Note: When not running a cluster simply set the delegation on the machine account that is running the SQL service and reboot the server.

    7) We are almost done now. We need to check the file server where the file is located that we want to import. If it is on another cluster make sure that cluster virtual resource name is enabled for Kerberos authentication as we did in step #1. If we are on a non-clustered file server then make sure we have the normal 2 HOST SPN’s registered. You can run the following command to check this:

    Setspn –L fileserver.contoso.com

    You should receive the two default HOST SPN’s back such as these:

    HOST/fileserver

    HOST/fileserver.contoso.com

    This is so we can continue to use Kerberos for authentication. Once this is setup you have to be able use Kerberos for authentication end to end or you will receive an error. If the file server is set up on a cluster as my customer then make sure the virtual name that is being accessed is set to use Kerberos authentication as we did in step #1. No need to set the virtual name here for the trusted for delegation as it is not needed.

    Ok, we should have things setup now. Let’s review what we have done:

    • We enabled the SQL Virtual Network resource for Kerberos authentication.

    We should have the following set to be trusted for delegation: SQL Virtual Network resource name, both of the cluster nodes and the SQL Service Account.

    • We set the proper user rights in the local security policy.
    • We have rebooted both of the cluster nodes.

    Now we can test the Kerberos authentication. Open either the Enterprise Manager or the SQL Management Studio application and run the following command:

    select auth_scheme from sys.dm_exec_connections where session_id=@@spid

    It should return Kerberos, if it does then we are successfully authenticating to SQL with Kerberos. Try your insert statement now and it should be able to import if you have the appropriate rights in SQL, the syntax of your command is correct and the format of the file you are importing are correct. If you should need any assistance with this then please contact the SQL Team Blogs which can be found here.

    References:

    956378 FIX: You may be unable to start the SQL Server agent if you configure a SQL Server 2005 failover cluster to use Kerberos constrained delegation for a domain user account

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;956378

    909801 How to make sure that you are using Kerberos authentication when you create a remote connection to an instance of SQL Server 2005

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;909801

    - Mark ‘DS? No, DB!’ Ramey

  • Name Suffix Routing

    Hello, David Everett here. I recently encountered an issue where authentication was failing across numerous forests after a second kerberos trust was made with a forest. Unlike most implementations of Active Directory which have a forest root and child domains that share a common DNS Namespace hierarchy, this customer had several forests sharing the same DNS Namespace, with CONTOSO.COM being the root of the DNS tree.

    The customer presented a very complex Visio diagram of their forests complete with all the trust relationships. While authentication issues were occurring in many of the forests I’m only citing those forests and domains that are of interest in an effort to simplify things.

    Existing Forests and Trust Relationships:

    The following trusts were already in place for about a year with no issues prior to the addition of a new forest trust:

    image

     

    A new two-way forest trust between CONTOSO.COM and TOWN.COUNTY.CONTOSO.COM was added and authentication in several forests began to fail.

    image

    Some of the errors encountered:

    After the second forest trust was added an Administrator of SUBDIVISION.TOWN.COUNTY.CONTOSO.COM logged onto a DC in SUBDIVISION and tried to connect to REALM.COUNTY.CONTOSO.COM in Active Directory Users and Computers only to get this error:

    Active Directory

    Windows cannot connect to the new domain because:
    The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

    When the SUBDIVISION administrator failed to connect the following event was logged in the System event log of the SUBDIVISION DC:

    Event Type:      Warning
    Event Source:    LSASRV
    Event Category:  SPNEGO (Negotiator)
    Event ID:        40960
    Date:            3/13/2009
    Time:            12:13:31 PM
    User:            N/A
    Computer:        SUBDC01
    Description:
    The Security System detected an authentication error for the server ldap/RELDC1.realm.county.contoso.com.  The failure code from authentication protocol Kerberos was "The name or SID of the domain specified is inconsistent with the trust information for that domain.
    (0xc000019b)".

    Here are some other events and errors you might see referencing domains in other forests that have trusts with the DC logging the event:

    Event Type:    Error
    Event Source:    KDC
    Event Category:    None
    Event ID:    12
    Date:        3/9/2009
    Time:        10:10:45 AM
    User:        N/A
    Computer:    SUBDC01
    Description:
    A request failed from client realm OTHER.NESTED.CONTOSO.COM for a ticket in realm TOWN.COUNTY.CONTOSO.COM. This failed because a trust link between the realms is non transitive.

    And

    Active Directory

    Windows cannot connect to the new domain because:
    Logon Failure: The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine.

    Understanding the Problem:

    When a Forest Trust is created a Name Suffix Route is dynamically added to both sides of the Forest Trust Properties. The Name Suffix Route is comprised of the DNS name suffix of the trusted forest root and a wildcard (*) precedes the DNS name suffix to allow for child domains to be trusted implicitly. The name suffix looks like this: *.CONTOSO.COM.

    Name Suffixes Routing controls routing of authentication traffic. When an account attempts to authenticate and that account does not exist in the local domain, the Name Suffix Route is used to direct authentication requests to the trusted forest root domain.

    Prior to the addition of the new forest trust a Name Suffix Route of *.CONTOSO.COM existed on the REALM.COUNTY.CONTOSO.COM side of the two-way forest trust between the REALM.COUNTY.CONTOSO.COM and CONTOSO.COM.

    image

    Problems only developed after the new two-way forest trust show below was added between CONTOSO.COM and TOWN.COUNTY.CONTOSO.COM. Authentication traffic from TOWN intended for REALM was being sent to CONTOSO. Likewise, authentication traffic from REALM intended for the TOWN forest was being sent to CONTOSO. This occurred because of a dynamically created Name Suffix Route of *.contoso.com that was added to the TOWN.COUNTY.CONTOSO.COM side of the trust.

    image

    In most environments the dynamically created Name Suffix Route of *.<forestroot>.<tld> would not cause issues. However, in this customer’s environment a Name Suffix Route of *.<forestroot>.<tld> caused all authentication requests to be sent to the wrong forest. Since the Forest is the security boundary authentication requests stopped at the CONTOSO.COM forest and did not implicitly follow the DNS Hierarchy.

    Correcting the problem:

    When more than two Forest reside in the same DNS namespace, and the root of that DNS tree is also an Active Directory forest, logic must be added to the Name Suffix Route to ensure authentication traffic is routed to the correct forest root. This can be accomplished by adding Exclusions to the Name Suffix Routes.

    1. Exclusions were added to the existing forest trust between REALM and CONTOSO. On the REALM side of the trust properties the following Exclusion had to be added to the *.CONTOSO.COM Name Suffix Route:

    TOWN.COUNTY.CONTOSO.COM

    NOTE: The * is automatically added in front of the suffix

    2. After the new two-way forest trust was created between TOWN and CONTOSO we added the following Exclusion to the *.CONTOSO.COM Name Suffix Route on the TOWN side of the trust:

    REALM.COUNTY.CONTOSO.COM

    NOTE: The * was automatically added in front of the suffix

    More reading:

    Routing name suffixes across forests

    http://technet.microsoft.com/en-us/library/cc784334.aspx

    Exclude name suffixes from routing to a local forest

    http://technet.microsoft.com/en-us/library/cc758388.aspx

    I hope you find this useful.

    UPDATE: Made changes to the diagrams to fix an error and makes things a bit more readable. Nice catch, Randy!

    - David ‘Monochrome’ Everett

  • Understanding DFSR debug logging (Part 14: A sharing violation due to a file locked upstream between two Windows Server 2008)

    In this scenario we will see file that is locked by an application, preventing replication from occurring. The upstream replicated folder will contain a file that does not yet exist on the downstream member. This is useful to understand as one of the most common troubleshooting areas in DFSR is in the area of sharing violation events.

     

    (lockedfileupstream - Dfsr00026 - 2008.log and lockedfiledownstream - Dfsr00023 - 2008.log)

     

    These are two Windows Server 2008 servers called 2008MEM01 and 2008MEM02 in the fabrikam.com domain. The logs are from 2008MEM01 (upstream) and from 2008MEM02 (downstream). Both servers are participating in the NEWRG1 replication group for the NEWRF1 replicated folder.  The locked file is called “setup.exe” and the file has been exclusively write-locked with a file utility to simulate the scenario. These two debug logs have been significantly trimmed to remove extraneous entries caused by the repro requirements.

     

    <Upstream> 20080627 15:50:40.249 3616 JOIN  1122 Join::SubmitUpdate LDB Updating ID Record: ß A file needs to be replicated out

    +       fid                             0x500000000AC91

    +       usn                             0xa9fe38

    +       uidVisible                      1

    +       filtered                        0

    +       journalWrapped                  0

    +       slowRecoverCheck                0

    +       pendingTombstone                0

    +       internalUpdate                  0

    +       dirtyShutdownMismatch           0

    +       meetInstallUpdate               0

    +       meetReanimated                  0

    +       recUpdateTime                   20080627 19:50:35.032 GMT

    +       present                         1

    +       nameConflict                    0

    +       attributes                      0x20

    +       ghostedHeader                   0

    +       data                            0

    +       gvsn                            {EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95

    +       uid                             {EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95 ß UID/GVSN match so this is an original file creation (in DFSR terms – if a file is copied into a replicated folder it is ‘created’ in DFSR terms).

    +       parent                          {05631532-B65C-45AF-BB49-F237ACB6CF7C}-v1

    +       fence                           16010101 00:00:00.000

    +       clockDecrementedInDirtyShutdown 0

    +       clock                           20080627 19:50:03.186 GMT (0x1c8d88efd9bd3de)

    +       createTime                      20080627 19:50:02.815 GMT

    +       csId                            {05631532-B65C-45AF-BB49-F237ACB6CF7C}

    +       hash                            00000000-00000000-00000000-00000000

    +       similarity                      00000000-00000000-00000000-00000000

    +       name                            setup.exe ß the file is named setup.exe

    +      

    <Upstream> 20080627 15:50:40.249 3616 JOIN  1167 Join::SubmitUpdate Sent: uid:{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95 gvsn:{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95 name:setup.exe connId:{FFC8C463-846D-4C16-8B37-19978C20FF8B} csId:{05631532-B65C-45AF-BB49-F237ACB6CF7C} csName:NewRF1 ß the upstream server submits update to its downstream partner

    <Downstream> 20080627 15:50:40.262 2424 DOWN  5186 [ERROR] DownstreamTransport::RdcGet Failed on connId:{FFC8C463-846D-4C16-8B37-19978C20FF8B} csId:{05631532-B65C-45AF-BB49-F237ACB6CF7C} rgName:NewRG1 update: ß the downstream server attempts to initiate replication of the file through RDC but receives an error

    +       present                         1

    +       nameConflict                    0

    +       attributes                      0x20

    +       ghostedHeader                   0

    +       data                            0

    +       gvsn                            {EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95

    +       uid                             {EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95

    +       parent                          {05631532-B65C-45AF-BB49-F237ACB6CF7C}-v1

    +       fence                           16010101 00:00:00.000

    +       clockDecrementedInDirtyShutdown 0

    +       clock                           20080627 19:50:03.186 GMT (0x1c8d88efd9bd3de)

    +       createTime                      20080627 19:50:02.815 GMT

    +       csId                            {05631532-B65C-45AF-BB49-F237ACB6CF7C}

    +       hash                            00000000-00000000-00000000-00000000

    +       similarity                      00000000-00000000-00000000-00000000

    +       name                            setup.exe

    +       Error:

    +       [Error:9027(0x2343) RpcFinalizeContext downstreamtransport.cpp:1096 2424 C A failure was reported by the remote partner]

    +       [Error:9027(0x2343) DownstreamTransport::RdcGet downstreamtransport.cpp:5124 2424 C A failure was reported by the remote partner]

    +       [Error:32(0x20) DownstreamTransport::RdcGet downstreamtransport.cpp:5124 2424 W The process cannot access the file because it is being used by another process.] ß the specific error is that the file is exclusively locked upstream

    <Downstream> 20080627 15:50:40.262 2424 INCO  5599 InConnection::LogTransferActivity Failed to receive RAWGET uid:{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95 gvsn:{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95 fileName:setup.exe connId:{FFC8C463-846D-4C16-8B37-19978C20FF8B} csId:{05631532-B65C-45AF-BB49-F237ACB6CF7C} stagedSize:0 Error: ß another error is logged for an attempted RAWGET of the same file

    +       [Error:9027(0x2343) DownstreamTransport::RdcGet downstreamtransport.cpp:5201 2424 C A failure was reported by the remote partner]

    +       [Error:9027(0x2343) RpcFinalizeContext downstreamtransport.cpp:1096 2424 C A failure was reported by the remote partner]

    +       [Error:9027(0x2343) DownstreamTransport::RdcGet downstreamtransport.cpp:5124 2424 C A failure was reported by the remote partner]

    +       [Error:32(0x20) DownstreamTransport::RdcGet downstreamtransport.cpp:5124 2424 W The process cannot access the file because it is being used by another process.] ß the file lock error is logged again

    ß <snipped out repeated attempts to replicate with same in use errors, for readability>

    <Upstream> 20080627 15:50:40.269 3132 SRTR  1880 SERVER_RequestVersionVector Received from connId:{FFC8C463-846D-4C16-8B37-19978C20FF8B} csId:{05631532-B65C-45AF-BB49-F237ACB6CF7C} seqNumber:3 changeType:notify

    <Upstream> 20080627 15:50:40.269 1248 MRSH  4615 Marshaller::Marshal FileAttrs in metadata : 0x20

    <Upstream> 20080627 15:50:40.279 3476 SRTR  1927 SERVER_AsyncPoll Received from connId:{D7E7B14C-8DE9-4198-BA51-B8D13867171D}

    <Upstream> 20080627 15:50:40.279 2932 OUTC   784 OutConnection::OpenFile Received request for update: ß there are repeated requests from the downstream to the upstream server to replicate the file

    +       present                         1

    +       nameConflict                    0

    +       attributes                      0x20

    +       ghostedHeader                   0

    +       data                            0

    +       gvsn                            {EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95

    +       uid                             {EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95

    +       parent                          {05631532-B65C-45AF-BB49-F237ACB6CF7C}-v1

    +       fence                           16010101 00:00:00.000

    +       clockDecrementedInDirtyShutdown 0

    +       clock                           20080627 19:50:03.186 GMT (0x1c8d88efd9bd3de)

    +       createTime                      20080627 19:50:02.815 GMT

    +       csId                            {05631532-B65C-45AF-BB49-F237ACB6CF7C}

    +       hash                            00000000-00000000-00000000-00000000

    +       similarity                      00000000-00000000-00000000-00000000

    +       name                            setup.exe

    +       rdcDesired:1 connId:{FFC8C463-846D-4C16-8B37-19978C20FF8B} rgName:NewRG1

    <Upstream> 20080627 15:50:40.279 2932 STAG   987 StageWriter::AbortDownloadStage Successfully aborted staging file 95-{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95-{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95-Downloading.frx. Deleted. ß after a number of attempts upstream to stage the file, the attempt is finally aborted. This is not a permanent condition, the DFSR service will try again later after waiting in the hopes that the file will unlock.

    <Upstream> 20080627 15:50:40.279 2932 ASYN   510 AsyncUnbufferedFileWriter::Close Async WRITE Statistics:

    <Upstream> 20080627 15:50:40.279 2932 EVNT   725 EventLog::Report Logging eventId:4304 parameterCount:8 ß a 4304 sharing violation (exclusive file lock) warning is logged in the event log.

    <Upstream> 20080627 15:50:40.279 2932 EVNT   745 EventLog::Report         eventId:4304 parameter1:05631532-B65C-45AF-BB49-F237ACB6CF7C

    <Upstream> 20080627 15:50:40.279 2932 EVNT   745 EventLog::Report         eventId:4304 parameter2:C:\NewRF1\setup.exe

    <Upstream> 20080627 15:50:40.279 2932 EVNT   745 EventLog::Report         eventId:4304 parameter3:C:\NewRF1

    <Upstream> 20080627 15:50:40.279 2932 EVNT   745 EventLog::Report         eventId:4304 parameter4:{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95

    <Upstream> 20080627 15:50:40.279 2932 EVNT   745 EventLog::Report         eventId:4304 parameter5:NewRF1

    <Upstream> 20080627 15:50:40.279 2932 EVNT   745 EventLog::Report         eventId:4304 parameter6:NewRG1

    <Upstream> 20080627 15:50:40.279 2932 EVNT   745 EventLog::Report         eventId:4304 parameter7:33DACEEE-D60C-4BF1-911C-EA5C487A78CB

    <Upstream> 20080627 15:50:40.279 2932 EVNT   745 EventLog::Report         eventId:4304 parameter8:5EF77FE2-B1BF-41B4-9DA6-51F6549F523E

    <Upstream> 20080627 15:50:40.300 2932 SRTR  2344 [WARN] InitializeFileTransferAsyncState::ProcessIoCompletion Failed connId:{FFC8C463-846D-4C16-8B37-19978C20FF8B} rdc:1 uid:{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95 gsvn:{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95 Error:

    +       [Error:32(0x20) UpstreamTransport::OpenFile upstreamtransport.cpp:1117 2932 W The process cannot access the file because it is being used by another process.]

    +       [Error:32(0x20) OutConnection::OpenFile outconnection.cpp:1618 2932 W The process cannot access the file because it is being used by another process.]

    +       [Error:32(0x20) OutConnection::GetReplicaReader outconnection.cpp:2289 2932 W The process cannot access the file because it is being used by another process.]

    +       [Error:32(0x20) NtfsFileSystem::MakeBackupReader ntfsfilesystem.cpp:526 2932 W The process cannot access the file because it is being used by another process.]

    +       [Error:32(0x20) MarshalFileReader::OpenFileId marshaller.cpp:4991 2932 W The process cannot access the file because it is being used by another process.]

    +       [Error:32(0x20) Marshaller::OpenSourceFile marshaller.cpp:4334 2932 W The process cannot access the file because it is being used by another process.]

    +       [Error:32(0x20) Marshaller::InitSourceFile marshaller.cpp:4205 2932 W The process cannot access the file because it is being used by another process.]

    +       [Error:32(0x20) MarshalContext::OpenFileForInfo marshaller.cpp:3320 2932 W The process cannot access the file because it is being used by another process.]

    +       [Error:32(0x20) MarshalContext::OpenFileForInfo marshaller.cpp:3237 2932 W The process cannot access the file because it is being used by another process.] completion:0 ptr:00E77D48

    ß <snipped out repeated attempts to replicate with same in use errors, for readability>

    <Downstream> 20080627 15:50:55.300 2424 MEET  1207 Meet::Install Retries:4 updateName:setup.exe uid:{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95 gvsn:{EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95 connId:{FFC8C463-846D-4C16-8B37-19978C20FF8B} csName:NewRF1 updateType:remote ß the downstream server has tried to replicate the file four times by now.

    <Upstream> 20080627 15:51:06.357 2932 CSMG  4844 ContentSetManager::UpdateHash LDB Updating ID Record: ß the file hash can finally be added to the DFSR database upstream as the file has been unlocked.

    +       fid                             0x500000000AC91

    +       usn                             0xa9fe38

    +       uidVisible                      1

    +       filtered                        0

    +       journalWrapped                  0

    +       slowRecoverCheck                0

    +       pendingTombstone                0

    +       internalUpdate                  0

    +       dirtyShutdownMismatch           0

    +       meetInstallUpdate               0

    +       meetReanimated                  0

    +       recUpdateTime                   20080627 19:50:35.032 GMT

    +       present                         1

    +       nameConflict                    0

    +       attributes                      0x20

    +       ghostedHeader                   0

    +       data                            0

    +       gvsn                            {EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95

    +       uid                             {EDE2D64E-1306-4C7C-B568-449A98371AA2}-v95

    +       parent                          {05631532-B65C-45AF-BB49-F237ACB6CF7C}-v1

    +       fence                           16010101 00:00:00.000

    +       clockDecrementedInDirtyShutdown 0

    +       clock                           20080627 19:50:03.186 GMT (0x1c8d88efd9bd3de)

    +       createTime                      20080627 19:50:02.815 GMT

    +       csId                            {05631532-B65C-45AF-BB49-F237ACB6CF7C}

    +       hash                            324AE6CC-5F635DEF-31E86733-00737CAA

    +       similarity                      1511151F-0C323F1B-0216212C-09171E20

    +       name                            setup.exe

    +      

    ß replication will proceed normally from this point.

     

    Understanding DFSR debug logging (Part 1: Logging Levels, Log Format, GUID’s)
    Understanding DFSR debug logging (Part 2: Nested Fields, Module ID's)
    Understanding DFSR debug logging (Part 3: The Log Scenario Format, File Added to Replicated Folder on Windows Server 2008)
    Understanding DFSR debug logging (Part 4: A Very Small File Added to Replicated Folder on Windows Server 2008)
    Understanding DFSR debug logging (Part 5: File Modified on Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 6: Microsoft Office Word 97-2003 File Modified on Windows Server 2008)
    Understanding DFSR debug logging (Part 7: Microsoft Office Word 2007 File Modified on Windows Server 2008)
    Understanding DFSR debug logging (Part 8: File Deleted from Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 9: File is Renamed on Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 10: File Conflicted between two Windows Server 2008)
    Understanding DFSR debug logging (Part 11: Directory created on Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 12: Domain Controller Bind and Config Polling on Windows Server 2008)
    Understanding DFSR debug logging (part 13: A New Replication Group and Replicated Folder between two Windows Server 2008 members)
    Understanding DFSR debug logging (Part 14: A sharing violation due to a file locked upstream between two Windows Server 2008)
    Understanding DFSR debug logging (Part 15: Pre-Seeded Data Usage during Initial Sync)
    Understanding DFSR debug logging (Part 16: File modification with RDC in very granular detail (uses debug severity 5))
    Understanding DFSR debug logging (Part 17: Replication failing because of blocked RPC ports (uses debug severity 5))
    Understanding DFSR debug logging (Part 18: LDAP queries failing due to network (uses debug severity 5))
    Understanding DFSR debug logging (Part 19: File Blocked Inbound by a File Screen Filter Driver (uses debug severity 5))
    Understanding DFSR debug logging (Part 20: Skipped temporary and filtered files (uses debug severity 5))
    Understanding DFSR debug logging (Part 21: File replication performance from throttling (uses debug severity 5))

    -          Ned Pyle

  • Conficker causes LSASS to consume CPU Time on Domain Controllers

    Hi Gautam here, I wanted to blog about a high-impact problem we have been seeing recently.

    The problem has to do with LSASS consuming a lot of CPU time on your Domain Controllers (DC's). The cause of this high CPU turns out to be Conficker infected computers throwing bad passwords against the DC's. The rate of bad passwords can be as high as 10,000 per minute from multiple clients.

    Technical information on Conficker can be found here.

    The problem could manifest itself in many ways, some being...

    1. Slow authentication and logons being reported by users,
    2. Slow mail flow
    3. Slow Resource access (resources could be Files shares, printers and more) or even complete failure in Resource access.

    Some of the above problems take time to be narrowed down. You typically will have to go through a few other pieces before you narrow down on the domain controllers being bogged down with high CPU time.

    Background:

    CPU usage on domain controllers continues to be very high (I'm rating high = 70% and above as long as this is not normal for the DC). On looking closer, you find LSASS.EXE eating up all of this CPU. Perfmon reports show the CPU usage stays more or less consistent throughout the day. It doesn't climb down during off-peak hours.

    As you can imagine, this high CPU usage affects other workflows which are AD dependent – including Exchange/SharePoint/Authentication etc.

    If you temporarily pull the network cable from the DC and wait a few minutes, LSASS drops back down to ~1% or whatever value is normal in your setup. Ned Pyle has the logic of pulling out the network cable described in a previous post in detail.

    In this case as well, we saw that pulling out the network cable brings down the LSASS CPU usage to normal limits. Plugging it back in makes LSASS shoot up again to 80%-90% CPU.

    If you follow the steps which Ned has documented in the blog, network traces will show a HUGE number of authentication requests coming into the DCs. Now it's not always easy to differentiate between bad and good traffic when you are looking at 100MB worth of network traffic.

    In this case however, what you are bound to see if something like the below in the network traces – I highly recommend using Netmon 3* - the Conversations feature is ideal to work through a large trace which you are bound to get when collecting network traces from the DC.

    09:54:16.593    192.168.0.1    DC01.CONTOSO.COM    KerberosV5    KerberosV5:AS Request Cname: User1 Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM

    09:54:16.625    DC01.CONTOSO.COM    192.168.0.1    KerberosV5    KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_FAILED (24)

    OR

    09:54:16.531    192.168.0.2    DC01.CONTOSO.COM    TCP    TCP:Flags=......S., SrcPort=4614, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=3314092510, Ack=0, Win=65535 ( ) = 65535

    09:54:16.531    DC01.CONTOSO.COM    192.168.0.2    TCP    TCP:Flags=...A..S., SrcPort=Microsoft-DS(445), DstPort=4614, PayloadLen=0, Seq=1831638666, Ack=3314092511, Win=17520 ( Scale factor not supported ) = 17520

    09:54:16.531    192.168.0.2    DC01.CONTOSO.COM    TCP    TCP:Flags=...A...., SrcPort=4614, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=3314092511, Ack=1831638667, Win=65535 (scale factor 0x0) = 65535

    09:54:16.531    192.168.0.2    DC01.CONTOSO.COM    SMB    SMB:C; Negotiate, Dialect = PC NETWORK PROGRAM 1.0, LANMAN1.0, Windows for Workgroups 3.1a, LM1.2X002, LANMAN2.1, NT LM 0.12

    09:54:16.531    DC01.CONTOSO.COM    192.168.0.2    SMB    SMB:R; Negotiate, Dialect is NT LM 0.12 (#5), SpnegoNegTokenInit

    09:54:16.578    192.168.0.2    DC01.CONTOSO.COM    SMB    SMB:C; Session Setup Andx, NTLM NEGOTIATE MESSAGE

    09:54:16.578    DC01.CONTOSO.COM    192.168.0.2    SMB    SMB:R; Session Setup Andx, NTLM CHALLENGE MESSAGE - NT Status: System - Error, Code = (22) STATUS_MORE_PROCESSING_REQUIRED

    09:54:16.593    192.168.0.2    DC01.CONTOSO.COM    TCP    TCP:Flags=...A...F, SrcPort=4614, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=3314092888, Ack=1831639470, Win=64732 (scale factor 0x0) = 64732

    09:54:16.593    DC01.CONTOSO.COM    192.168.0.2    TCP    TCP:Flags=...A...F, SrcPort=Microsoft-DS(445), DstPort=4614, PayloadLen=0, Seq=1831639470, Ack=3314092889, Win=17143 (scale factor 0x0) = 17143

    09:54:16.593    192.168.0.2    DC01.CONTOSO.COM    TCP    TCP:Flags=...A...., SrcPort=4614, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=3314092889, Ack=1831639471, Win=64732 (scale factor 0x0) = 64732

    Now, in the above three examples of network traffic, the first one with the Kerberos KDC_ERR_PREAUTH_FAILED is a sure shot bad password attempt. The other two traces aren't necessarily always bad authentication attempts, but is data connections to LSARPC which I saw on three of the four recent cases I had with this issue.

    SPA reports will show high number of calls to SAMSRV or LSARPC. Tim Springston, who runs his own excellent AD related blog, has discussed the using of SPA here.

    With TOP users attained from both SPA and from the Network traces, we explored 3 of the top client computers. We pulled MPSReports (an often used PSS Data collection tool) from these client computers. The first thing which stood out in the event logs was all the Audit Failures Logon/Logoff Event Id 529's in the Security Event logs.

    Note: by default, only Success for Logon/Logoff and Account Logon is enabled. And in this case, the Domain Controllers were running with the defaults. The client computers had Failure for Logon/Logoff enabled.

    More..

    This of course led us to...

    1. Checking this customer's account lockout policy –we saw they did not have account lockouts enabled
    2. We enabled Failure for Account Logon on a policy which applied to the Domain Controllers as well.

    No sooner had the failure-audit policy applied to the DC, the Security event logs were filled with Audit Failures Account Logon Event Id 675. Here is an example of a 675 event.

    Event Type:    Failure Audit
    Event Source:    Security
    Event Category:    Account Logon
    Event ID:    675
    Date:        3/23/2009
    Time:        3:03:57 AM
    User:        NT AUTHORITY\SYSTEM
    Computer:    DC01
    Description:
    Pre-authentication failed:

        User Name:    User1
        User ID:        %{S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxxx}
        Service Name:    krbtgt/CONTOSO.COM
        Pre-Authentication Type:    0x2
        Failure Code:    0x18
        Client Address:    192.168.0.100 ß IP of the computer which is throwing the bad credentials

    Using EVENTCOMBMT to pull out the relevant event Ids from various DCs (namely 529, 644, 675, 676, and 681) and a little bit of Office Excel magic, I quickly had a list of ~100 computers sending bad passwords within a 30 minute time frame. The total number of failed logons were enough to drive up the LSASS.EXE CPU usage. LSASS ofcourse was only doing its job of keeping up with the load and failing the bad authentication attempts.

    Putting it all together:

    The kind of (multiple user logons from a single computer) and the rate (100's of attempts per minute per computer) at which they were throwing bad passwords, were a pretty sure sign of malware activity. A few more client computers, which we picked up from the SPA and Netmon reports, revealed traces of Conficker. With the Microsoft PSS Security team and the customers own Antivirus vendor involved, they were able to patch, scan, and clean their computers and this effort showed the LSASS CPU usage on the DCs drop down dramatically.

    So from high LSASS CPU – to network traces leading to TOP client computers – to security events – to DC security events – back to the client computers! As you can imagine, it took some time in nailing down the first time. The 2nd, 3rd and 4th cases were nailed down to unpatched computers infected by Conficker way quicker.

    I hope with this blog post out, someone will save themselves a LOT of time and effort when facing such an issue.

    • Gautam Anand
  • Understanding DFSR debug logging (Part 17: Replication failing because of blocked RPC ports (uses debug severity 5))

    In this scenario we will see a file created on the upstream server and attempted replication with its downstream partner. RPC traffic is being blocked between the machines by an incorrectly configured firewall. This is a common scenario and basic understanding of firewalls, TCP/IP, ports, and RPC is assumed. Debug logging severity is set to 5 in order to see more details about the problem state.

     

    (rpcportsblocked - Dfsr00008 - 2008.log)

     

    These are two Windows Server 2008 servers called 2008x86SRV10 and 2008x86SRV11 in the contoso.com domain. The log is from 2008x86SRV10 where the file is created (upstream). Both servers are participating in the RpcPortRG replication group for the RpcportRf replicated folder. The file is called “fveupdate.exe”.

     

    <Upstream> 20080908 10:12:45.417 3372 USNC  2612 UsnConsumer::CreateNewRecord LDB Inserting ID Record: ß File added to the replicated folder on the upstream server

    +       fid                             0x300000000BAAC

    +       usn                             0x2633c60

    +       uidVisible                      0

    +       filtered                        0

    +       journalWrapped                  0

    +       slowRecoverCheck                0

    +       pendingTombstone                0

    +       internalUpdate                  0

    +       dirtyShutdownMismatch           0

    +       meetInstallUpdate               0

    +       meetReanimated                  0

    +       recUpdateTime                   16010101 00:00:00.000 GMT

    +       present                         1

    +       nameConflict                    0

    +       attributes                      0x20

    +       ghostedHeader                   0

    +       data                            0

    +       gvsn                            {5CB120DE-D2C2-452A-8280-B45FC155224F}-v28

    +       uid                             {5CB120DE-D2C2-452A-8280-B45FC155224F}-v28

    +       parent                          {3C47E305-FDE9-43F6-A550-791D9568C1D3}-v1

    +       fence                           16010101 00:00:00.000

    +       clockDecrementedInDirtyShutdown 0

    +       clock                           20080908 17:12:43.261 GMT (0x1c911d61b214f69)

    +       createTime                      20080908 17:12:43.261 GMT

    +       csId                            {3C47E305-FDE9-43F6-A550-791D9568C1D3}

    +       hash                            00000000-00000000-00000000-00000000

    +       similarity                      00000000-00000000-00000000-00000000

    +       name                            fveupdate.exe ß file is name ‘fveupdate.exe’

    +      

    <Upstream> 20080908 10:12:45.417 1632 DOWN  3363 DownstreamTransport::SetupBinding Setup connId:{108028D9-F00E-4F1E-A8EF-BF60DB623231} remoteAddress:2008x86FSRV11.contoso.com  stringBinding:[5bc1ed07-f5f5-485f-9dfd-6fd0acf9a23c@ncacn_ip_tcp:2008x86FSRV11.contoso.com] ß An RPC connection setup attempt occurs over TCP (using the UUID of DFSR, which is the GUID 5bc1ed07-f5f5-485f-9dfd-6fd0acf9a23c) between upstream and downstream server

    <Upstream> 20080908 10:12:45.433 3372 USNC  2615 UsnConsumer::CreateNewRecord ID record created from USN_RECORD:

    +       USN_RECORD:

    +       RecordLength:        88

    +       MajorVersion:        2

    +       MinorVersion:        0

    +       FileRefNumber:       0x300000000BAAC

    +       ParentFileRefNumber: 0xD00000000BA35

    +       USN:                 0x2633c60

    +       TimeStamp:           20080908 10:12:43.261 Pacific Standard Time

    +       Reason:              Basic Info Change Close Data Extend Data Overwrite File Create

    +       SourceInfo:          0x0

    +       SecurityId:          0x0

    +       FileAttributes:      0x20

    +       FileNameLength:      26

    +       FileNameOffset:      60

    +       FileName:            fveupdate.exe

    +      

    <Upstream> 20080908 10:12:45.433 3372 LDBX  4300 Ldb::UpdateLastVersion Updating lastVersion:28

    <Upstream> 20080908 10:12:45.433 3372 USNC  3459 UsnConsumer::CheckPoint Updating journalRecord: updateFlags=0

    +       usnId:                              0x1c8b6df35167c8c

    +       nextUsn:                            0x26360f8

    +       checkpointUsn:                      0x2633c60

    +       checkpointTimestamp:                20080908 17:12:43.261

    +       journalWrapped:                     0

    +       journalIdChanged:                   0

    +       slowRecoverNotFinished:             0

    +       dirtyRecoveryMode:                  0

    +       dirtyShutdownRecoveryTimestamp:     16010101 00:00:00.000

    +       dirtyRecoveryRecordsMarkedFinished: 0

    +      

    <Upstream> 20080908 10:13:04.246 2508 SETT   153 Settings::GenericDwordSetting::operator () Assigned default value. valueName:RpcContextHandleTimeoutMs value:1800000

    <Upstream> 20080908 10:13:04.246 2508 SETT   153 Settings::GenericDwordSetting::operator () Assigned default value. valueName:MinRateCounterUpdateIntervalSec value:29

    <Upstream> 20080908 10:13:06.433 1632 DOWN  3868 [WARN] DownstreamTransport::EstablishConnection Failed. Try flat name. ß RPC connection has failed

    +       [Error:9027(0x2343) DownstreamTransport::EstablishConnection downstreamtransport.cpp:3853 1632 C A failure was reported by the remote partner] ß returns error 9027

    +       [Error:1722(0x6ba) DownstreamTransport::EstablishConnection downstreamtransport.cpp:3853 1632 W The RPC server is unavailable.] ß returns extended error 1722 (“The RPC server is unavailable”)

    <Upstream> 20080908 10:13:06.433 1632 DOWN  3099 DownstreamTransport::SetupBinding Entering SetupBinding

    <Upstream> 20080908 10:13:06.433 1632 DOWN  3181 DownstreamTransport::SetupBinding Setting authentication information for partner: CONTOSO\2008X86FSRV11$ ß the partner that was being connected to

    <Upstream> 20080908 10:13:06.433 1632 DOWN  3363 DownstreamTransport::SetupBinding Setup connId:{108028D9-F00E-4F1E-A8EF-BF60DB623231} remoteAddress:2008x86FSRV11.contoso.com  stringBinding:[5bc1ed07-f5f5-485f-9dfd-6fd0acf9a23c@ncacn_ip_tcp:2008x86FSRV11]

    <Upstream> 20080908 10:13:27.434 1632 DOWN   383 LogExtendedErrorInformation Extended error information: ß various extended error information is logged for troubleshooting purposes. All are from WINERROR.H and can be translated with err.exe

    +       Process ID           : 3148 ß process ID of DFSR.EXE

    +       System Time          : 20080908 17:13:27.434

    +       Generating component : 2

    +       Status               : 1722

    +       Detection location   : 501

    +       Flags                : 0

    +       NumberOfParameters   : 4

    +               0 Unicode string: [ncacn_ip_tcp]

    +               1 Unicode string: [2008x86FSRV11]

    +               2 Long          : -1988219297

    +               3 Long          : 1722

    <Upstream> 20080908 10:13:27.434 1632 DOWN   383 LogExtendedErrorInformation Extended error information:

    +       Process ID           : 3148

    +       System Time          : 20080908 17:13:27.434

    +       Generating component : 8

    +       Status               : 1722 ß Error “The RPC server is unavailable”

    +       Detection location   : 1442

    +       Flags                : 0

    +       NumberOfParameters   : 1

    +               0 Unicode string: [2008x86FSRV11]

    <Upstream> 20080908 10:13:27.434 1632 DOWN   383 LogExtendedErrorInformation Extended error information:

    +       Process ID           : 3148

    +       System Time          : 20080908 17:13:27.434

    +       Generating component : 8

    +       Status               : 1237 ß error “The operation could not be completed. A retry should be performed.”

    +       Detection location   : 313

    +       Flags                : 0

    +       NumberOfParameters   : 0

    <Upstream> 20080908 10:13:27.434 1632 DOWN   383 LogExtendedErrorInformation Extended error information:

    +       Process ID           : 3148

    +       System Time          : 20080908 17:13:27.434

    +       Generating component : 8

    +       Status               : 10060 ß error “A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.”

    +       Detection location   : 311

    +       Flags                : 0

    +       NumberOfParameters   : 3

    +               0 Long          : 135

    +               1 Pointer       : 00000000

    +               2 Pointer       : 6F000A0A00000000

    <Upstream> 20080908 10:13:27.434 1632 DOWN   383 LogExtendedErrorInformation Extended error information:

    +       Process ID           : 3148

    +       System Time          : 20080908 17:13:27.434

    +       Generating component : 8

    +       Status               : 10060

    +       Detection location   : 318

    +       Flags                : 0

    +       NumberOfParameters   : 0

    <Upstream> 20080908 10:13:27.434 1632 DOWN   373 LogExtendedErrorInformation Done enumerating extended error information

     

    Understanding DFSR debug logging (Part 1: Logging Levels, Log Format, GUID’s)
    Understanding DFSR debug logging (Part 2: Nested Fields, Module ID's)
    Understanding DFSR debug logging (Part 3: The Log Scenario Format, File Added to Replicated Folder on Windows Server 2008)
    Understanding DFSR debug logging (Part 4: A Very Small File Added to Replicated Folder on Windows Server 2008)
    Understanding DFSR debug logging (Part 5: File Modified on Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 6: Microsoft Office Word 97-2003 File Modified on Windows Server 2008)
    Understanding DFSR debug logging (Part 7: Microsoft Office Word 2007 File Modified on Windows Server 2008)
    Understanding DFSR debug logging (Part 8: File Deleted from Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 9: File is Renamed on Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 10: File Conflicted between two Windows Server 2008)
    Understanding DFSR debug logging (Part 11: Directory created on Windows Server 2003 R2)
    Understanding DFSR debug logging (Part 12: Domain Controller Bind and Config Polling on Windows Server 2008)
    Understanding DFSR debug logging (part 13: A New Replication Group and Replicated Folder between two Windows Server 2008 members)
    Understanding DFSR debug logging (Part 14: A sharing violation due to a file locked upstream between two Windows Server 2008)
    Understanding DFSR debug logging (Part 15: Pre-Seeded Data Usage during Initial Sync)
    Understanding DFSR debug logging (Part 16: File modification with RDC in very granular detail (uses debug severity 5))
    Understanding DFSR debug logging (Part 17: Replication failing because of blocked RPC ports (uses debug severity 5))
    Understanding DFSR debug logging (Part 18: LDAP queries failing due to network (uses debug severity 5))
    Understanding DFSR debug logging (Part 19: File Blocked Inbound by a File Screen Filter Driver (uses debug severity 5))
    Understanding DFSR debug logging (Part 20: Skipped temporary and filtered files (uses debug severity 5))
    Understanding DFSR debug logging (Part 21: File replication performance from throttling (uses debug severity 5))

     

    -          Ned Pyle

  • One stop Audit shop for ADAM and ADLDS

    Hello, Linda Taylor here, I am an Escalation Engineer in the Directory Services support team in the UK. I do a lot of work with ADAM and ADLDS. One of frequent subjects for questions for ADAM/ADLDS is around auditing. We have lots of very good documents on TechNet about ADAM and ADLDS which briefly mention auditing, but there isn't one single document where you can find all auditing related information.  So this should be helpful! 

    Note: information here applies to both ADAM and ADLDS unless otherwise stated.  To be current with things I will use LDS to refer to ADAM and ADLDS.

    First is first: Auditing is supported on WS03 (ADAM) and WS08 (ADLDS) but not in XP. Auditing is also improved in ADLDS with the new DS Access auditing categories

    Q: So what do you need to configure directory service access auditing in LDS?

     

    There are 3 things:

    1. Enable auditing via GPO

    2. Set the SACL on the object in LDS which you want to audit

    3. The LDS service account must be granted 'generate security audit' right on the servers where LDS runs. Network Service or Local System have this by default so if you are running ADAM service under one of these then no need to do anything.

    >>>See below for details of each of these steps.

     

    Q. What can we audit using GPO?

     

     Through GPO we have a number of options under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit policy.

    But not all of these can be used/apply to LDS / ADAM.

    ·         There are 2 Audit settings here that are relevant to LDS:

    1. Audit Directory Service Access.

    As described this allows you to audit access to objects in LDS directory.

    Note: in WS08 we added the new categories to DS Access auditing see Q&A section at the bottom.

     

    2.  Audit Account Logon Events

    This allows you to get a security log audit on the LDS machine when a native LDS user connects/binds to an instance.  

     

    ·         Settings which do not make sense for ADLDS:

    - Audit Account Management doesn't work for ADLDS. This one probably deserves an explanation as to why....This is because ADLDS user objects are viewed by Windows simply as objects stored in some directory which is independent of the operating system (so they are not SAM account objects).. Whose object class name happens to be "user". By Default ADLDS doesn't contain any user class so we are free to define anything and call it user class. Therefore the standard account management auditing doesn't apply.

    -Audit Object access, Audit Policy change, Process Tracking and System Events also doesn't make sense for ADLDS since it applies to things like file objects, and policies which do not exist in the LDS database.

    Q: How do I set up auditing for LDS?

    So going back to the steps at the beginning of this doc:

    1. Set up Group policy - enable DS Access auditing / account logon auditing (or both).

    There are a few scenarios for this. Most people seem to be running LDS on domain joined machines so for this scenario either:

     (a) The audit policy is usually set at the domain level in the Default Domain GPO. This then applied to all machines in the domain so your LDS server may be getting these settings in this way.

    (b) You can put your LDS machines in an OU and create a specific GPO there to enable any audit settings if they are not enabled at domain level. This way any settings in the GPO will not affect the rest of the machines in your domain so it’s less of a risk.

    The third option is for an LDS server in a workgroup. In this scenario you can simply configure auditing thought local Group Policy.

    I won't go through the steps on how to configure Group Policy here as the main purpose of this article is to discuss auditing in LDS and ADAM. However you can find more information about Group Policy in TechNet by searching for "Group Policy". A good place to start could also be the "Windows Server Group Policy" home page here: http://technet.microsoft.com/en-us/windowsserver/grouppolicy/default.aspx

    Note: don't forget to refresh group policy on the LDS machine after doing any modifying. (run gpupdate / force)

    2.  (a) For Directory Service Access Auditing - Set up the SACL in LDS.

    For this you can use LDP.exe and its SACL Editor. (If you are on WS03 R2 or WS03 ADAM SP1 then you will need to make sure that you use the version of LDP.exe that comes with ADAM). Other ways of setting the SACL are thought dsacls.exe or scripting. Here I will give a simple LDP.exe example:

    Steps:

    1.Start LDP.exe and connect and bind to your ADLDS instance using an account which has permissions to edit SACL's. So for example the admin account of your LDS instance.

    NOTE:  In order to be able to see and edit ACE's in LDS you need to bind using a windows account (local or domain which has admin rights in LDS and the SESecurityPrivilege privilege on the LDS machine). If you bind with an LDS user account you will be unable to view, edit or add any ACE's . The windows will simply be blank and if you try to add an ACE you will get an "Error:Modify:Insufficient Rights <50>" when you try to update the SACL.

    This is because Security administrators are users who have been assigned the Manage Auditing and Security Log (SeSecurityPrivilege) privilege. By default, this privilege is assigned to the built-in Administrators  group in windows. ADAM users have no concept of privileges so it is not possible to assign an ADAM user this privilege.

    2. From the "View" menu you can select <Tree> and leave the DN blank. This will enumerate all your partitions.

    3. Navigate to the object which you want to audit access to and right click it. Then go to "advanced ->Security Descriptor" . A small Security Descriptor window will pop up with DN of your application partition. Select   the SACL check box and click <OK>.  Now you will see a dialog like this:

     

    In the top you can see the owner of the object. In the middle pane there is the DACL section and right under there you can see the SACL box. For you it may be empty to start with. So you just need to click inside it to focus the tool on the SACL part.

    4. Click in the SACL box or select a SACL to edit.

    5. Click on <Add ACE> (or <Edit ACE>)and you will get a new pop up box where you can add the trustee (so the account/group you want to monitor) and choose which operations and attributes you want to audit. As well as choose if you want to audit success or failure and if you want to propagate this ACE to child objects.

    6. When finished click OK and click update in the SD dialog. (Make sure SACL is checked - default)

    Note: A WS03 ADAM instance will not generate SAM-style audits (636). It can only generate DS-style audits (566), which are controlled by SACLs on objects.

    The 566 audit does not show the actual values being written, but it will say that user X updated attribute X on object X. In WS08 we added a capability to audit actual values being written. See Q3 below on how to enable this.

    2. (b) Logon auditing.

    No more configuration needed. LDS user bind auditing goes into the security log on the ADAM server. Look for event 680. This will tell you which ADAM user connected and to which instance as well as the source workstation IP and various other details.

    Example event:

    Event Type:         Success Audit

    Event Source:     Security

    Event Category:                Account Logon

    Event ID:              680

    Date:                     25/02/2009

    Time:                     11:14:37

    User:                     S-1-340980651-3826302016-2572561877-1280810218-2114187174-3140415964

    Computer:          LINDAK-01

    Description:

    Logon attempt by:          ADAM_adlds1

     Logon account:                CN=user1,OU=Users,DC=ADLDS

     Source Workstation:      127.0.0.1

     Error Code:        0x0

     

    3. The LDS service account must be granted 'generate security audit' right on the servers where LDS runs.  Network Service or Local System have this by default so if you are running ADAM service under one of these then no need to do anything. If you are running ADAM service as a local user account or a domain account you will need to give the user account this right. To do so you can use Local group policy and add the "Generate Security Audit" rights under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignments.

    Other audit Q&A:

     

    Q1: How do I audit password changes for ADAM and ADLDS users? 
    Set up appropriate SACLs. You will want to audit the use of Change Password (and perhaps Reset Password) control access right on user objects. 

    Q2: How do I audit replication events  in ADAM?

    To enable replication auditing for an ADAM instance, you must modify the registry key:

    HKLM\System\CurrentControlSet\Services\instance_name\Parameters

    Where instance_name represents the name of the ADAM instance on which you want to audit replication. The following table describes the values in the registry key that control replication auditing. To enable replication auditing, set one or both of the values to 1.

     

    Registry key value

    Data type

    Meaning

    Audit Access in Replication

    DWORD

    Provides a summary of the replication operations that are occurring.

    Audit Objects in Replication

    DWORD

    Audits the changes to individual objects and attributes.

     

    Once enabled Look for Events in the security log on the ADAM server under the category "Directory Service Access".  (Note this also means you need to have DS Access auditing enabled via GPO as above). The event logged will show which object was modified, and which attribute. Including the new value.

    Note note: this won't tell you who changed an object so if that is important I suggest you set a SACL on the desired object/container or choose WS08 ADLDS and the new auditing.

    Q3. How I enable the new WS08 detailed object access auditing for ADLDS?

    In Windows Server 2008 you can now set up AD DS auditing with a new audit subcategory to log old and new values when changes are made to objects and their attributes. For this to work on AD LDS you will need to use auditpol just like for DS.  

    The  AD DS Auditing Step-by-Step Guide can be found here: http://technet.microsoft.com/en-us/library/cc731607.aspx  and applies to AD LDS though the steps given are AD DS specific.

     

    So here is how to make it work for AD LDS:

     

    1.       The GPO part is the same - use auditpol to enable the additional categories. Here is a link to auditpol commands - http://technet.microsoft.com/en-us/library/cc731451.aspx

    Notes: There are a couple of different scenarios:

     

    (a)  If you have a WS08 ADLDS member server in WS03 domain, then if you enabled "Directory Access Auditing" via group policy (See above "How do I set up auditing in LDS?") then you don't need to do anything!! This turns on all 4 categories under DS Audit.

     - run auditpol /get /category:* on the WS08 machine and it will show the following:

     

    DS Access

      Directory Service Changes               Success and Failure

      Directory Service Replication           Success and Failure

      Detailed Directory Service Replication  Success and Failure

      Directory Service Access                Success and Failure

     

    Note: ADLDS will take advantage and log all the new events in this scenario.

     

                    (b) if you have WS08 ADLDS server in a workgroup or a WS08 domain. In this case you will           need  to turn on the additional sub-categories of DS Access auditing.  Only "Directory Service               Access"  is on by default. For example to turn on "Directory Service Changes" run the following    command: auditpol /set /subcategory:"Directory Service Changes" /success:enable

     

    2.       The SACL part I have documented above in section 2(a)

    3.       The additional Schema controls (searchFlags)  are the same for AD LDS Objects.

     

    Example:

     

    In ADLDS I used LDP to set a SACL on the NC head partition to audit "create child, delete child, write property, delete tree, delete". I also set the "inherit" flag. For trustee I added the CN=administrators  group in that ADLDS partition.  I then created a new user in this partition, and  moved it into an OU. The following Events are logged in the security log:

     

    ·         For the user creation (I cut out the relevant bits to save space):

    <snip>

    Event ID:      5137

    ...

    Description:

    A directory service object was created.

    Subject:

                    Security ID:                         lindakup\Administrator

                    Account Name:                 Administrator

                    Account Domain:                             lindakup

                    Logon ID:                             0xfcceb

    Directory Service:

                    Name:  ADAM_blogTest

                    Type:     Active Directory Lightweight Directory Services

    Object:

                    DN:        CN=Linda,OU=europe,dc=adamblog

                    GUID:    {23995da1-f623-414d-8a6e-a02376e8c666}

                    Class:    user

    </snip>

                           

     

    ·         A  5136 event for every attribute that I added to my user object.

    <snip>

    Event ID:      5136

    ...

    Description:

    A directory service object was modified.

    Subject:

            Security ID:                         lindakup\Administrator

            Account Name:                 Administrator

            Account Domain:                             lindakup

            Logon ID:                             0xfcceb

     

    Directory Service:

            Name:  ADAM_blogTest

            Type:     Active Directory Lightweight Directory Services

    Object:

            DN:        CN=Linda,OU=europe,dc=adamblog

            GUID:    {23995da1-f623-414d-8a6e-a02376e8c666}

            Class:     user

    Attribute:

            LDAP Display Name:       objectClass

            Syntax (OID):     2.5.5.2

            Value:   1.2.840.113556.1.5.9      

    Operation:

            Type:     Value Added

            </snip>

     

    ·         Finally for the object move:

     

    <snip>

    Event ID:      5139

    Task Category: Directory Service Changes

    ...

    A directory service object was moved.

           

    Subject:

            Security ID:                         lindakup\Administrator

            Account Name:                 Administrator

            Account Domain:                             lindakup

            Logon ID:                             0xfcceb

           

    Directory Service:

            Name:                  ADAM_blogTest

            Type:                     Active Directory Lightweight Directory Services

           

    Object:

            Old DN:                                OU=MiddleEast,DC=adamblog

            New DN:              OU=MiddleEast,OU=Countries,DC=adamblog

            GUID:                    {d0385bd8-adea-4916-a656-dd49770848d0}

            Class:                     organizationalUnit

    </snip>

     

    Q4. How do I enable auditing of object deletion in ADLDS?

    Good news! The new DS Auditing category "Directory Service Changes" will report object deletions in WS08 ADLDS.

    Look for Event 5145. This will tell you which object was deleted, when and by whom.    

     

    Finally Good Links:

     

    ·         ADAM 2003 Technical Reference: http://technet.microsoft.com/en-us/library/cc736765.aspx

    ·         ADLDS documentation includes step-by-step guide and operations guide here:http://technet.microsoft.com/en-us/library/cc731868.aspx

    ·         More ADLDS resources: http://technet.microsoft.com/en-us/library/cc816744.aspx

     - Linda Taylor