Blog - Title

November, 2007

  • Introducing Group Policy Preferences

    Hi, Mike here. Have you ever wanted to map a drive for specific users at logon—without using a logon script? Have you ever wanted to change the local administrator’s password on all your client computers? Have you ever wanted to add items to a user’s Start menu? Now you can with Windows Server 2008, which includes Group Policy preferences.

    What are Group Policy preferences? Group Policy preferences allow administrators to configure and deploy Windows and application settings that were previously unavailable using Group Policy. The Windows Server 2008 Group Policy Management Console (GPMC) includes Group Policy preferences, which are available when editing domain-based Group Policies. Also, you can manage Group Policy preferences from a Windows Vista Service Pack 1 computer by installing the Remote Server Administration Tools (RSAT), which included the updated version of GPMC.

    You first notice a change in the namespace and node structure when editing a domain-based Group Policy object with GPMC. Computer and User Configuration remain; however there are now two categories under each configuration: Policies and Preferences.

    clip_image002

    Figure 1- Group Policy Preferences nodes

    The Policies node contains the familiar node structure found when editing earlier versions of Group Policy. The Preferences node contains all the preference settings, which are a categorized into Windows Settings and Control Panel Settings.

    clip_image004

    Figure 2- Windows and Control Panel Settings

    With Group Policy preferences there are many different ways to accomplish a specific task. Each Group Policy preference extension provides configuration properties specific to the extension and common among most preference extensions.

    clip_image006

    Figure 3 – Extension specific configuration properties

    Preference items allow you to fine tune how they apply to users and computer by offering sophisticated targeting features. Using the targeting editor, you can create various targeting conditions to ensure the correct preference item applies to the correct user or computer.

    clip_image008

    Figure 4 - Targeting Editor

    The Client-Side Extensions for GP Preferences are included in Windows Server 2008, and down-level versions will be available as a separate download for:

    1. Windows XP Service Pack 2 and above
    2. Windows Vista RTM and above
    3. Windows Server 2003 SP1 and above

    Finally, it’s important to understand that Group Policy preferences are just that – preferences. Unlike policy-enabled components that apply managed policy settings, preferences simply configure the settings as if a person did it. Users can change these settings until the next refresh of Group Policy. For example, when you use Group Policy to configure a screensaver, the option to change it is unavailable (grayed out) for the user. When using preferences, the screensaver is preconfigured per the preference settings; however, the user still has the ability to change the settings (until the next Group Policy refresh—depending on how you configure the preference item).

    You can read more details on Group Policy preferences by downloading the Group Policy preferences whitepaper from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=103735)

    - Mike Stephens

  • Cool Auditing Tricks in Vista and 2008

    Hi, Ned here again. Today I’m going to show some interesting new features of Auditing in Windows Vista and Windows Server 2008 that can be used for troubleshooting problems or seeing what’s happening in your environment. I’ll be building upon some of the basic information Dave Beach talked about in ‘Introducing Auditing Changes in Windows 2008’. This is not designed to be the be-all, end-all (in fact, I hope to write some further follow-ups on this), but it should definitely help get the creative juices flowing and help people turn to auditing more often than they have in the NT-2003 days.

    First, let’s quickly revisit the changes. Vista and 2008 now support granular auditing, meaning that instead of a couple large categories you can specify very specific elements to be audited. The advantage here is that instead of turning on Object Access auditing then wading through miles of chaff, you can get something as specific as just network file share usage information, or just account lockouts, or just process creation. To see all your options execute (from an elevated CMD prompt):

    auditpol /list /subcategory:*

    This will return all the new categories and subcategories. To deploy these types of changes in a Domain-based environment, follow ‘How to use Group Policy to configure detailed security auditing settings for Windows Vista client computers in a Windows Server 2003 domain or in a Windows 2000 domain’.

    If you’re troubleshooting though and just want to make some specific audit changes to a computer in a domain, there’s an easier way:

    Via GPEDIT.MSC

    1. Open the Group Policy Object Editor (GPEDIT.MSC).
    2. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.
    3. Double-click

    Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.

    4. Click ENABLED, and then click OK.
    5. Restart the machine.

    Via REGEDIT.EXE

    1. Open the Registry Editor (REGEDIT.EXE)
    2. Locate and then click the following registry subkey:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA

    3. Add a new DWORD value of SCENoApplyLegacyAuditPolicy
    4. Set the value data to 1
    5. Close REGEDIT and restart the machine.

    After making this change the computer will no longer apply auditing security policy even when specified in domain-based group policies; this way your changes won’t get overwritten as we proceed. You can read more about this in KB921468.

    It’s critical to realize that something else important happened in Windows Vista and 2008 – Crimson. We finally rewrote the 15-year old Event Service first delivered in NT3.1, and now there are no longer the old scalability and reliability problems with event logs. Need a 16GB security log? No sweat, it can handle it. Plenty more on this here.

    So let’s do some cool things with this new system…

    Find out when users on Vista are elevating their programs with UAC

    Here’s a common scenario: User Account Control is enabled and the users have been added to the Administrators group on their Vista clients. You need to know how often and for what reasons they are elevating their so-called ‘split tokens’. Maybe it’s for audit trail, maybe it’s to identify applications that might need to be updated or rewritten to not need admin credentials, or maybe you just want to prove that when a user complains he gets prompted ‘all the time’ you can respond with ‘Really? Seems like it was just twice this week!’

    1. We enable the “Process Creation” subcategory of “Detailed Tracking” category with:

    Auditpol.exe /set /subcategory:"process creation" /success:enable

    2. We let things cruise for a few days with the user cranking away on his system.3. We connect to the machine with EVENTVWR.EXE using ‘Connect to Another Computer’
    4. We set a filter by selecting Windows Logs -> Security then select Filter Current Log. We set a filter for Event ID of 4688 like so:

    clip_image002

    5. This removes everything from our view except Process Creation events.
    6. We now do a Find for TokenElevationTypeFull (2) and we see things like:

    Log Name: Security
    Source: Microsoft-Windows-Security-Auditing
    Date: 11/6/2007 4:44:57 PM
    Event ID: 4688
    Task Category: Process Creation
    Level: Information
    Keywords: Audit Success
    User: N/A
    Computer: nedpyle04.fabrikam.com
    Description:
    A new process has been created.

    Subject:
     
    Security ID: FABRIKAM\nedpyle
    Account Name: nedpyle
    Account Domain: FABRIKAM

    Logon ID: 0x329656f

    Process Information:
    New Process ID: 0xe44
     
    New Process Name: C:\Windows\System32\awfulapp.exe
     Token Elevation Type: TokenElevationTypeFull (2)
    Creator Process ID: 0x35c

    Token Elevation Type indicates the type of token that was assigned to the new process in accordance with User Account Control policy.

    Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account.

    Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group.

    Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.

    Did I mention the actual audit descriptions are useful now? :) I might not have known what TokenElevationTypeFull meant, but the event is there to tell me all about it.

    Find out who is making AD changes unrelated to Accounts, using Windows Server 2008

    Another favorite is “who the heck has been messing with group policy?!” In this scenario we have a number of OU’s that are managed by branch and group policy administrators. These users have been delegated rights to control group policy for their respective only. After time though, you are finding that some of them are making changes that contravene IT policies and standards. What’s worse, there are several people with rights to make changes and no one is admitting anything. How can we figure this out?

    By default, Active Directory OU’s are already configured with audit entries that track group policies being linked, blocked, or enforced – so we don’t have to muck around in ADSIEDIT or AD Users and Computers this time. So let’s get on with the rest:

    1. Enable the auditing subcategory of “Directory Service Changes”, either via AUDITPOL on all DC’s or KB921469. This means going forward you’re tracking people making changes in DS, for anything you have configured to be auditable.

    We wait for the hammer to drop…

    2. Finally, someone makes one of these changes we don’t like. On any computer joined to that domain running Windows Support Tools, we execute:

    repadmin /showmeta "ou=remote branch,dc=cohowinery,dc=com"

    … which is the OU we cared about. It returns:

    9 entries.
    Loc.USN Originating DSA Org.USN   Org.Time/Date Ver Attribute
    ======= =============== ========= ============= === =========
    <Snipped out goo>
    22653 Default-First-Site-Name\2008SRV10 22653 2007-11-08 19:20:57 5 gPLink
    22650 Default-First-Site-Name\2008SRV10 22650 2007-11-08 19:20:45 3 gPOptions

    So now we know the when and the where – someone changed group policy links and enforcement on Nov 8 at 7:20PM. We need the who and the what.

    We crack open the EVENTVWR on our Windows Server 2008 DC named (imaginatively named ‘2008SRV10’). We filter for 5136 events and see:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          11/8/2007 7:25:56 PM
    Event ID:     5136
    Task Category: Directory Service Changes
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      2008SRV10.cohowinery.com
    Description:
    A directory service object was modified.

    Subject:
        Security ID:        COHOWINERY\Robert
        Account Name:       Robert
        Account Domain:     COHOWINERY
        Logon ID:           0x4bcc5f

    Directory Service:
        Name:    cohowinery.com
        Type:    Active Directory Domain Services

    Object:
        DN:    OU=Remote Branch,DC=cohowinery,DC=com
        GUID:  OU=Remote Branch,DC=cohowinery,DC=com
        Class: organizationalUnit

    Attribute:
        LDAP Display Name:    gPOptions
        Syntax (OID):    2.5.5.9
        Value:    1

    Operation:
        Type:    Value Added
        Correlation ID:    {8d929c75-e7c8-47a2-9592-835041973fc1}
        Application Correlation ID:    -

    And:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          11/8/2007 7:26:06 PM
    Event ID:      5136
    Task Category: Directory Service Changes
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      2008SRV10.cohowinery.com
    Description:
    A directory service object was modified.

    Subject:
        Security ID:        COHOWINERY\Robert
        Account Name:       Robert
        Account Domain:     COHOWINERY
        Logon ID:           0x4bcc5f

    Directory Service:
        Name:    cohowinery.com
        Type:    Active Directory Domain Services

    Object:
        DN:      OU=Remote Branch,DC=cohowinery,DC=com
        GUID:    OU=Remote Branch,DC=cohowinery,DC=com
        Class:   organizationalUnit

    Attribute:
        LDAP Display Name:    gPLink
        Syntax (OID):    2.5.5.12
        Value:    [LDAP://cn={2CC9A70E-DAD5-4707-B1C1-3EE8DC565AC8},cn=policies,cn=system,DC=cohowinery,DC=com;0]

    Operation:
        Type:    Value Added
        Correlation ID:    {cf7540ef-037e-4d6c-bd72-4654561762d5}
        Application Correlation ID:    -

    GPoptions is an AD attribute that marks ‘Block Policy Inheritance’ – being set to 1 means that this OU will no longer receive policies linked at a higher level than itself. Since we’re setting some policies at the domain level, this is probably not cool!

    GPLink is an AD attribute that lists out which policies are linked to an OU (or site, or domain) and whether it’s enforced or not (0 or 1). It contains a value that points to an actually policy object.

    So above, we see now that Robert is our culprit. He’s been blocking corporate group policies specified at the domain, and he’s also linking policies at his own OU. Since he’s allowed to link, let’s see what he actually added. We can either run Windows Server 2008’s built-in ADSIEDIT.MSC or we can execute a command.

    clip_image004

    Executing (this is all one line):

    dsquery * "cn={2CC9A70E-DAD5-4707-B1C1-3EE8DC565AC8},cn=policies,cn=system,DC=cohowinery,DC=com" -scope base -attr displayname

    Which returns:

    displayname
    Install Specially Licensed Software

    Well heck – he’s also linking a policy that installs some software that we have limited licensing. And of course, he’s not supposed to. But now we know…

    Find out what is changing a registry value at random intervals

    Finally, let’s discuss another common problem – at unpredictable intervals, something or someone is making registry changes on Vista computers. You suspect it’s a script or application, but you’re not sure how to figure out the source. Since it takes so long to happen you can’t just stare at the machine, so you decide to enable some auditing.

    For this specific scenario, we have a handful of Vista machines that keep ending up in the wrong AD Logical Site. These machines were specially configured in the past to go to a specific site called FLURG rather than use dynamic site coverage.

    So here’s what the registry looks like when everything is right:

    clip_image006

    1. We open REGEDIT and navigate to

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters

    2. We right click and choose Permissions. We click Advanced, then Auditing. We add Everyone like below, making sure to only choose ‘This Key Only’ and Set Value for Successful. The reasoning here is that we only want this specific data and no sub-keys that might exist, we only want to see something writing data (certainly not querying!), and we don’t care if it fails.

    clip_image008

    3. We then enable the auditing subcategory of ‘Registry’ under ‘Object Access’ like so:

    Auditpol.exe /set /subcategory:"Registry" /success:enable

    We already know this isn’t going to happen for days, and we sure as heck don’t want to keep walking over to this machine every few hours, so let’s configure a subscription to tell us when things change.

    4. We turn on the Windows Remote Management service on the affected machine:

    winrm quickconfig

    … which returns:

    WinRM is not set up to allow remote access to this machine for management.
    The following changes must be made:

    Set the WinRM service type to delayed auto start.
    Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
    Enable the WinRM firewall exception.

    Make these changes [y/n]? y <-- enter y here and hit <enter>

    WinRM has been updated for remote management.

    WinRM service type changed successfully.
    Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
    WinRM firewall exception enabled.

    5. We start that Windows Remote Management service.

    6. We then go into EVENTVWR on our own administrative machine (not the problem machine!) and click Subscriptions. We then select Create Subscription, which gives us a dialog we can fill out:

    clip_image010

    7. Make sure to hit advanced and add a user account with rights to access that machine. If you want to get alerts ASAP select the option for Minimize Latency.

    clip_image012

    8. We then choose ‘Select Events’ and add our filter so that we get Informational events (which Security events always fall under), matching 4657, and auditing success only.

    clip_image014

    So now, all Event 4657 occurrences on the problem machine will be forward to our own machine. But let’s not stop there; after all, I still don’t want to stare at Event Viewer all day at my desk. Let’s make it tell us when something interesting happens, by adding a special kind of scheduled task on our workstation:

    schtasks /create /tn EventLog /tr eventvwr.exe /sc onevent /ec ForwardedEvents /mo *[System/EventID=4657]

    This command adds a scheduled task which:

    • Monitors the Forwarded Events log channel
    • Looks for 4657 events showing up
    • Starts Event Viewer for us when it all happens

    So a few days go by and we’re sitting at our desk enjoying some light reading when suddenly Event Viewer opens. Woohoo! We look at the Forwarded Events and see:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          11/6/2007 7:38:50 PM
    Event ID:      4657
    Task Category: Registry
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      nedpyle04.fabrikam.com
    Description:
    A registry value was modified.

    Subject:
        Security ID:        FABRIKAM\billybob
        Account Name:       billybob
        Account Domain:     FABRIKAM
        Logon ID:           0x329656f

    Object:
        Object Name:       \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\Netlogon\Parameters
        Object Value Name: SiteName
        Handle ID:         0x124
        Operation Type:    Existing registry value modified

    Process Information:
        Process ID:        0x930
        Process Name:      C:\Windows\System32\reg.exe

    Change Information:
        Old Value Type:   REG_SZ
        Old Value:        Flurg
        New Value Type:   REG_SZ
        New Value:        Nargle

    There’s our guy. We walk over and chat with Billy Bob and he admits he’s got a script he’s been using that shells REG.EXE to make some registry changes. And wouldn’t you know it, there’s some old recycled code in it that explains our issue. High five.

    I hope this post helped you get familiarized with Vista and Windows Server 2008 auditing capabilities. Please let us know one way or the other.

    - Ned Pyle

  • How to troubleshoot Certificate Enrollment in the MMC Certificate Snap-in

    Hi, Seth Scruggs here from the Directory Services team. Today I’m going to discuss how to troubleshoot certificate enrollment in Windows using a Windows Server 2003 Certification Authority (CA). Before you read on, make sure you have the Windows Server 2003 Resource Kit, the Windows Server 2003 or Windows XP Support tools, and the Windows Server 2003 admin pack installed. All will be needed for troubleshooting!

    There are four ways we enroll for certificates in Windows:

    1. MMC based enrollment
    2. Auto Enrollment
    3. Web Enrollment
    4. Manual Enrollment (certreq.exe, lcscertutil.exe, etc)

    This blog is going to specifically cover how to troubleshoot enrollment through the MMC Certificate Snap-in. If you are troubleshooting auto enrollment, the first step is to always try MMC-based enrollment; if you find this fails, there is no point troubleshooting auto enrollment until MMC-based enrollment works.

    We call this MMC enrollment because we do this from the Certificates snap-in that can be added to an MMC. To use this snap-in, click Start | Run | MMC. Then in the blank MMC, click File | Add/remove snap-in | Certificates. I am specifically writing this blog to cover user based enrollment (as opposed to computer based enrollment), but the concepts can be applied to both.

    MMC or snap-in based enrollment breaks in one of two spots; when you launch the wizard or when you click finish at the end of the wizard.

    Troubleshooting errors when you launch the wizard

    Let’s start by doing a high level walkthrough of the beginning steps and understand why it might fail here:

    1. We first query Active Directory and search for a list of available CAs. When the client retrieves the result of the query, it filters out the results based on the following:

    • Is this an Enterprise CA?
    • Do I trust this CA?
    • Am I sure this CA isn’t revoked?
    • Do I have permissions to the CA?

    2. Then we query Active Directory for a list of certificate templates. When the client retrieves the result of the query, it filters out the results based on the following:

    • Do I have enroll permissions on any certificate templates?
    • Are any of the templates that I have enroll permissions on available on the CA/s we identified before?
    • Is the template configured correctly to allow for enrollment in the MMC?

    If the combination of these filters leaves your template or CA list blank, then you receive an error when you launch the wizard:

    image

    Do you have this error? Let’s use some tools and troubleshoot this. If you don’t see this error when you launch the Request Wizard, you can read this next section just for fun or skip this and go directly to “Troubleshooting errors when you click finish at the end of the Wizard”.

    Querying Active Directory

    We started by looking for CAs that are published in AD. Specifically, the client does an LDAP query for objects in the following container:

    CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com

    This container should hold one object for every internal Windows CA installed in the forest. If for some reason the user doesn’t have permission to read this container, the objects beneath it, or there are no objects beneath it, we fail. By default Authenticated Users have read access on this container; so start by verifying this is the case in your forest. We’re going to use ADSIEdit.msc from the Windows Support tools to look at permissions.

    Launch ADSIEdit.msc, then expand CN=Configuration | CN=Services | CN=Public Key Services | CN=Enrollment Services. This should look like:

    image

    You can see from the screen shot that in my lab there is one object under CN=Enrollment Services. If you don’t have an object in your environment (but you know you have a CA) then something went wrong during installation or an administrator in your forest deleted the object. In either case, you can re-populate the object by logging on to the CA as an Enterprise Admin or Forest Root Domain Admin and doing a backup and restore of the CA in the CertSrv.msc console.

    If you have verified that one or more objects actually exist in the CN=Enrollment Services, let’s check permissions. Right click on the CN=Enrollment Services container, select properties and then click on the Security tab. We should see that Authenticated Users have read permission on the container.

    image

    If Authenticated Users is not listed here, you’ll need to add this group and assign Read Permissions to this container and any child container beneath it.

    You could reset permission on the container to the default permissions as defined by the schema using DSACLS.exe, but this is a shotgun approach and you could remove any custom permissions that were previously delegated to this container. If you feel like doing it anyways, the syntax is here:

    DSAcls “CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com” /S

    OK, so you made sure Authenticated Users have read permissions on CN=Enrollment Services, and you made sure that there is actually one or more objects in the container. The next step is to make sure that your CA is an Enterprise CA and that the object/s in ADSIEDit.msc reflect this. We’ll do this in two steps.

    First, logon to your CA and at the command prompt run certutil –cainfo. In the output find the field labeled CA type. If it says Enterprise Subordinate CA or Enterprise Root CA then we are fine. If it displays Standalone Root or Standalone Subordinate CA then MMC enrollment will not be possible and you must choose another request method.

    After you have verified that you actually have an Enterprise CA, let’s look at the CA object in ADSIEdit.msc and make sure the flag that identifies it as an Enterprise CA is set correctly. It is very unusual to see the flag set incorrectly, but all the same it is possible. As we did before, launch ADSIEdit.msc, then expand CN=Configuration | CN=Services | CN=Public Key Services | CN=Enrollment Services. Right click the CA in the right pane that you want to enroll from and click properties. Find the flags attribute; and verify that it is set to 10. If it isn’t set to 10, then set it to 10 using ADSIedit.msc and allow for Active Directory replication to complete.

    image

    Verifying the CA certificate

    The next step is to make sure that I trust the CA, and that I can make sure the CA is not revoked. Certificate verification is kind of a big topic, and I’m going to barely touch it. If you want in-depth knowledge, you can read this whitepaper.

    The easiest way to verify do this is to launch PKIView.msc (available in the Windows Server 2003 Resource Kit). Once open, right click on Enterprise PKI and select Manage AD Containers. When this opens, click on the Enrollment Services tab.

    image

    We can already tell that the user trusts this CA, because the status is OK. This can be a bit misleading, but is a good start. Now let’s do an in-depth verification:

    Highlight the certificate and click View. When the certificate dialog box opens, click on the Details tab, then click Copy to file. Export the certificate as a .cer file (DER or Base-64 encoding is fine). At the command prompt, run certutil –verify C:\filename.cer >verifyresults.txt, replacing C:\filename.cer with the path and file name of the certificate file you exported. After it runs, open verifyresults.txt and scroll down to the very bottom. Any error message at the bottom indicates a chaining or revocation checking problem; either of which would cause an enrollment to fail.

    A common chaining problem looks like this:

    A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. 0x800b0109 (-2146762487)
    ------------------------------------
    Verifies against UNTRUSTED root

    If you see a chaining error message, make sure that the root certificate is installed in the trusted root store. You also might have to make sure any intermediate certificates are installed in the intermediate store.

    A typical revocation error looks like this:

    ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).

    CertUtil: The revocation function was unable to check revocation because the revocation server was offline.

    If you see a revocation checking error message, run certutil –verify –urlfetch C:\filename.cer >urlfetch.txt. Open urlfetch.txt and find the CDP sections of the output. In this section, examine each path and figure out why this client isn’t able to reach the path. A client doesn’t need to be able to reach all paths, but does need to be able to reach at least one path for each CA. An example looks like this:

    ---------------- Certificate CDP ----------------
    Failed "CDP" Time: 0
    Error retrieving URL: The specified network resource or device is no longer available. 0x80070037 (WIN32: 55)
    ldap:///CN=2003Dom%20Enterprise%20Issuing%20CA,CN=2003DOMCA01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=2003Dom,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

    Failed "CDP" Time: 0
    Error retrieving URL: The server name or address could not be resolved 0x80072ee7 (WIN32: 12007)

    http://2003domca01.2003dom.com/CertEnroll/2003Dom%20Enterprise%20Issuing%20CA.crl

    In this case you can see we can’t get to either CRL distribution point URL. Again, we don��t need to get to both, but we have to be able to get to one of them.

    Request Permissions

    If everything looks good with chaining and revocation status, let’s move on to CA request permissions. Permissions are placed on the CA and are saved on the object that is stored in the Enrollment Services container. To verify the client has permission to request from the CA, open CertSrv.msc on the CA, right click on the name of the CA, and then click on the Security tab. By default Authenticated Users have the Request Certificates permission. If Authenticated Users don’t have this permission, make sure that the client requesting the certificate is a member of some group that does have this permission.

    image

    Querying Active Directory (again)

    At this point we have queried for CAs that are available in the forest and we have filtered down our list. If we have identified one or more valid CAs, we do another LDAP query for all of the Certificate Template objects in the following container:

    CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com

    First we look at the permissions on each object returned, and determine if the client has Read and Enroll permissions on the certificate template. An easy way to verify permissions is to logon as the requesting user and run certutil –template on the client (on XP, you must install the Windows Server 2003 Admin pack to use this utility). This will dump all of the certificate templates in the CN=Certificate Templates container; and if the user doesn’t have permission to one of them it will display Access is Denied next to that template.

    image

    If the certificate template you want to use has an Access is Denied next to it check the user’s group memberships and/or the permissions on the Certificate Template. To verify group membership of the user, you can run whoami /groups (whoami is part of the Windows Support tools on XP and included in the OS with Windows Server 2003). To check permissions on the certificate template, open CertTmpl.msc, find and double click the certificate template you want, then go to the security tab. If you are making constant changes to this stuff, remember that AD replication latency is a factor.

    OK, now that we have confirmed permissions are OK, let’s make sure this CA offers the certificate template we want. The Wizard does this by looking at the Certificate Templates attribute on the objects in CN=Enrollment Services. We can do this by opening certsrv.msc on the CA, then clicking on the Certificate Templates folder. All you need to do is make sure you see the desired template in the list:

    image

    If your certificate template is in the list, then you’re good. If not, right click on Certificate Templates, select New Certificate Template to issue, and then choose the correct template to add.

    Verifying Certificate Template Settings

    The last thing to check is if the template settings allow it to ever show up in the MMC. If the Certificate Template is set to supply the subject name in the request, it will never appear in the MMC because the MMC (in 2K/XP/2003) doesn’t allow you to enter this value. For the template to be offered in the MMC, the subject name must be built from Active Directory. The setting on the template should look like one of these:

    image image

    At this point we have covered all of the reasons that a request through the MMC Snap-in might initially fail. Let’s look at what happens when you finish the wizard, and why that might fail.

    Troubleshooting errors when you click finish at the end of the Wizard

    Let’s do a high level walkthrough of the process when you click the Finish button in the wizard:

    1. We use the settings from the selected Certificate Template to build a certificate request.
    2. Send the request to the CA using an RPC connection and receive it back.

    If one of these steps fails, you could receive a few different errors, but the most common is:

    image

    Let’s break down the steps and figure out why we might see this error message.

    We start by reading the certificate template settings and building a request. To do this, we use the Cryptographic Service Provider (CSP) specified by the template (or chose one locally based on the template setting) to generate a key pair and create a key container to store the private key. Then we sign the data in our request with the private key and store the request locally in the Pending Request certificate store.

    The most common cause of failure in this step is permissions on the directory where we create key containers. For a user, we create the private key container in the user’s profile in:

    %userprofile%\Application Data\Microsoft\Crypto\RSA\<SID of user>

    If you look, you might find that you already have dozens of files in this directory; or you could have none. What is important is that the permissions on this directory look like this; with all three security principals having inherited full control.

    image

    If yours isn’t like this, restore them to defaults. This should be:

    Administrators Full Control
    <The Username> Full Control
    SYSTEM Full Control

    These should be inherited, and apply to This Folder, subfolders, and files. If this looks good and we are sure that writing to this directory isn’t our problem, let’s move on to the next step.

    Submitting the request to the CA

    Once we build the request, we send it to the CA using DCOM/RPC. Using the dnsHostName attribute on the CA’s object in CN=Enrollment Services, we grab the DNS name of the server, resolve the server name using DNS, then send an RPC end point mapper (EPM) request to the CA over port 135. The EPM on the CA returns a port to which the client may send the request. In order for any of this DCOM magic to work, both the client and the CA must have DCOM enabled and configured correctly. Check on your client and server by opening the Component Services snapin: Start | Run | DCOMCNFG. Once open, expand Component Services | Computers | My Computer. Right click on the Default Properties tab. It should look like this on both the client and server:

    image

    Now let’s check for port connectivity. As I stated before, we must have access to port 135; in addition to this the random port range that must be open is 1024 – 65534. This can be changed, but is out of scope for this blog. For additional information check out the ports article.

    There are many ways to test connectivity; including telnet.exe, network traces, or portqryui.exe. We are going to use Port Query. Before we test connectivity, let’s find out which ports the CertSrv.exe service is listening on. Since the port is allocated from a dynamic range and is a moving target, we’ll need to do this in two steps. First, dump the list of processes on the Certificate Server:

    Tasklist >tasklist.txt

    Open this file, and find the PID (process ID) of the certsrv.exe process (in this case it is 1152)

    image

    Second, find out which ports are open by PID:

    Nestat –ano >ports.txt

    Open this file, and find each instance of your PID (again, my PID was 1152). It is expected to see more than one port open for this process, since we have multiple interfaces for the service. We are interested in the port bound to 0.0.0.0, in this case port 1104.

    image

    So, we have two ports of interest, 1104 and 135. Now download, extract, and launch portqryui.exe on the client. Enter the IP or FQDN of the server that hosts Certificate Services, choose Manually input query ports, and enter the port you found plus port 135.

    image

    You can see in the output that port 135 was identified as the endpoint mapper and is LISTENING (this is good). Now scroll down to the bottom and look for the evaluation of port 1104.

    image

    Again, LISTENING, so we shouldn’t have any connectivity issues.

    After checking port connectivity, the next step is to consider DCOM permissions on the CA. In Windows 2K3 SP1, we hardened security on the CertSrv Request DCOM interface. Basically, we create a new Local group called CERTSVC_DCOM_ACCESS and only allow members of this group permission to hit this interface. On a member server, this group is local and it contains the Everyone group. However, if the CA is installed on a domain controller, we create the group as a domain local group and add Domain Users and Domain Computers from that domain. The problem is that this doesn’t include the Domain Controllers group; or the Users, Computers, or Domain controllers from any other domain in the forest.

    A good article on this change is here. Basically, make sure that your user is in a group that is a member of the CERTSVC_DCOM_ACCESS group. If you have Windows Server 2003 with SP1 or higher and you don’t see this group, follow the steps in the article to recreate the group using certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG. Again, if the CA is on a DC, it will be a Domain Local group, otherwise it will be a regular local group.

    Keep in mind that if you make adjustments to the group by adding new members, the client must be restarted to build its logon token. One way to test permissions (and connectivity) is to run certutil –config FQDN\CAName –ping at the command prompt on the client where FQDN is the fully qualified name of the server and CAName is the subject name of the certificate for that CA. An example would be:

    certutil –config “server01.contoso.com\Contoso Enterprise Sub CA” –ping

    If you don’t have permission to the DCOM interface, an Access is Denied message will be returned.

    Conclusion

    Well, that is about it. Hopefully if you are troubleshooting an issue your problem is now resolved. These steps obviously won’t fix all issues, but easily the top 90%. Please feel free to add comments or other questions!

    Other reading:

    281260 A Certificate Request That Uses a New Template Is Unsuccessful
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;281260

    833704 "The certificate request failed because of one of the following conditions" error message when you request a certificate in ISA Server 2004
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;833704

    929494 Error message when you request a certificate from a computer that is running Windows Server 2003 with Service Pack 1: "The certificate request failed because of one of the following conditions…"

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

    903220 Description of the changes to DCOM security settings after you install Windows Server 2003 Service Pack 1
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;903220

    - Seth Scruggs

  • What's in a Token

    Hi, Randy here. This is my first blog post to help explain authentication and authorization. This post will be helpful in understanding "Access is Denied" messages and how to troubleshoot when these happen. I'd like to start with an explanation of the security token.

    When you log on to a system, you provide credentials in order to gain access to resources to which you have permission. You typically set these permissions by going to the security tab in the properties window of an object and add a user to the list along with the access that you either allow or deny. The security token is how this list (referred to as the Access Control List (ACL), validates you to allow or deny access. The token is an object representing your credentials and an access check is a search of the ACL to see if there is an entry with your name on it. So what about group membership? Security groups are a way to simplify security administration. If we are able to group users together, we can define an entry in the access control list for the security group instead of defining an entry for every user in your environment.

    Here are two screenshots. The first screenshot is of the ACL on the security properties page of an NTFS folder named Tools. Notice that it lists each of the user or group names and their permissions. The second picture is of the same ACL but with communication blocked to the domain controller. Because we cannot reach a domain controller, we cannot resolve the friendly names in the list and they are displayed as security identifiers (SIDs), for example S-1-5-21-1712426984-1618080182-1209977580-1108.  Security identifiers are how computers see users and groups and will be discussed in more detail later in this post. In the second picture we see our local group resolve to a friendly name Administrators. This is because our local computer manages local groups while the domain controller manages domain groups.

    clip_image002 clip_image004

    When you first log on to your computer, you prove your identity by typing your username and password or validating with a smartcard. A domain controller validates these credentials and returns your user information and group membership. Your workstation uses this information to compare against its security policy and local security groups to build a security token that will accurately represent you, your domain and local group memberships, and all privileges you have to that computer. It is important to remember that your domain group membership is only part of the token; much of the security token is based on information local to the machine where the token is built. This means that your token may be different when it is built on your workstation of which you are an administrator and built on a file Server where you may have more limited access rights.

    A good tool to view the contents of a token is TokenSZ. Below are two separate outputs of TokenSZ for a user named Randy in the domain Wingtiptoys.com. The first one is from an XP workstation where I am the local administrator. The second output is from a file server (where I am not a local administrator that) hosts a share that I often access. I used the command tokensz /compute_tokensize /dump_groups

    clip_image006

    clip_image008

    Notice the output on my client workstation has more data, but much of this information is very similar between the two outputs. The first portion of both outputs reference information on the Kerberos ticket and the size of the token that is generated. This information is not relevant for this discussion, but if you would like to read more about this output and issues where this information is important, please see the whitepaper Addressing Problems Due to Access Token Limitation.

    The first portion is the Security Identifier for our User:

    · User

    S-1-5-21-1712426984-1618080182-1209977580-1108

    This number is the unique SID for the user account. This string is what a computer sees when validating access and privileges. When we looked at the Security tab of a directory earlier in this discussion, we saw that the ACL is actually populated with these SIDs. The ACL editor user interface communicates with a domain controller to translate SIDs into friendly names to make our jobs a little easier. You can determine the SID of a friendly name using PSGetSid. Also, the Microsoft Script Center has an article on how to do this in a script with WMI.

    Now let’s look at how this number is generated. The first three segments S-1-5 are called the revision level. You will see S-1-5 quite often, this means it is revision level 1 and generated by the Windows Security_NT_Authority. The second 4 segments is the domain identifier, 21-1712426984-1618080182-1209977580. This is a unique number for a domain. If this SID was for a local user account or group, the domain identifier would be a unique number representing that computer. The last dash is the Relative Identifier (RID), 1108, which makes this number unique to any other SID in the domain.

    The next portion shows the SIDs for the enumerated groups and where the two outputs differ.

    · Groups:

    00   S-1-5-21-1712426984-1618080182-1209977580-513    Attributes - Mandatory Default Enabled
    01   S-1-1-0          Attributes - Mandatory Default Enabled 
    02   S-1-5-32-544               Attributes - Mandatory Default Enabled Owner 
    03   S-1-5-32-545               Attributes - Mandatory Default Enabled 
    04   S-1-5-2          Attributes - Mandatory Default Enabled 
    05   S-1-5-11        Attributes - Mandatory Default Enabled 
    06   S-1-5-21-1712426984-1618080182-1209977580-1110  Attributes - Mandatory Default Enabled

    This is the enumeration of all the domain and local groups. Notice that the group list contains different local groups even though we are the same user on the two machines. When my identification was returned from the domain controller, my local workstation checked its local group membership to determine that my domain account is a local administrator to that computer and added this to our token (S-1-5-32-544). We can tell that the domain identifier is 21-1712426984-1618080182-1209977580. If we were a member of a local group created on the box or in a security group in a trusted domain, that entry would have a different domain identifier in its SID. So why are some of these SIDs missing some parts? S-1-5-11 is one example. This is a well known security identifier. These are generic groups that are predefined to the workstation or domain and required for basic functionality. It is important that these security groups have the same SID regardless of domain membership. This way everything does not break if you move a computer into another domain or into a workgroup. If you look through the list in the article, you will see that several of these well known SIDs go beyond simple group membership and are used to define properties of the specific session, such as if these credentials are used as a batch job (S-1-5-3) or as a service (S-1-5-6.)

    The next portion defines the Primary Group of the User

    · Primary Group:

    S-1-5-21-1712426984-1618080182-1209977580-513

    This is not relevant to our discussion but is used for compatibility for the POSIX subsystem.  When a user creates an object it will set that object’s primary group to that of the user creating it. The -513 identifies this as the Domain Users group.

    The next portion of the token represents privileges. The privileges represent certain actions that this token can perform local to the machine where it was built. These are basic activities such as "log on locally" or "start as a service" or "shutdown the computer." These actions define how much control a user will have to system-wide resources and will often permit the user to call these functions regardless of object-based permissions that may be set. Some of these privileges control logon access to a computer and will block or permit a user from establishing a session to the computer or connecting to the computer altogether. These privileges are defined in a computer's security policy and use the user and group security objects to define who has these privileges. Privileges are another way to perform an access check when actions are more complicated than just matching up to an access control list of an object. When comparing the token output above, you see that we have numerous privileges available to us on the workstation where we are a local administrator versus on the file server. Many of these privileges can be traced back to Windows NT 3.1 and were managed using NTRights. You can still use NTRights to script these privileges, but now they are typically defined in group policy under Computer Configuration\Security Settings\Local Policies\User Rights Assignment.

    Whoami is included in Windows Server 2003 and Vista and is available for download for Windows 2000 and Windows XP. Although running Whoami with no switches only returns the name of the currently logged on user, the tool has much more functionality. Whoami /user will show the SID of the logged on user. Whoami /groups displays group membership for the current user, and Whoami /priv shows the security privileges of the current user. An important thing to note about the Whoami /priv output is that the current user has all privileges listed in the output, regardless if the State shows Enabled or Disabled. The State column indicates if the privilege is currently being used, not whether the user actually has that privilege. So if a privilege shows up in the list at all, you have it. Whoami /priv is always an easy way to demonstrate some of the differences between a full security token in Windows Vista versus a restricted token. Just run Whoami /priv under both an elevated and non-elevated command prompt in Vista to see the difference.

    To summarize, a security token lists SIDs representing your user account and domain and local group membership. Some of these groups are defined by administrators and others are defined by the operating system based on characteristics of your session. Your token also contains rights and privileges granted by the machine where the token was built. It is important to know that these tokens are unique to every system and how you may access them; whether it is an interactive logon, access of a network resource or credentials passed by a service or batch file. With token in hand, we have proof of our identity and can present this token when accessing a protected object. A good analogy is viewing your token as a key ring; each security identifier and privilege is a different key that may or may not fit the lock placed on objects by the security subsystem. So now we need to look at where these tokens are and who uses them.

    I will not be going into great detail on Windows internals, but it will be helpful to understand processes and object management. A process is an activity running on your computer. A process can be an application that you open, or a service that starts, or a task of the operating system, but everything a computer does can be identified as a process. When a process is created, it includes a primary token, representing the credentials used to run the process. The token may represent the local computer account, a service account, or user account based on what it does and how it was created. When a user logs on, the Winlogon process starts a process under the user’s security context. By default this is Explorer.exe, the interactive graphical user interface shell in Windows. This process contains a token that was based on the information collected about the logged on user. Explorer needs access to a resource, it can present that token. Whenever you perform an activity on your desktop, it initializes a child process from the original Explorer.exe. A child process retains the token from its parent and passes this token to any additional processes that it spawns. This is why people have the impression that when they authenticate, everything they do is performed using their security credentials. But not all processes stem from explorer.exe. There are several activities happening that are initiated by the local computer or specify their own credentials, like a service that uses a service startup account. When you troubleshoot authorization, it is important to recognize that each process running may or may not be using the credentials of the person typing at the keyboard or moving the mouse. You can see this using Process Explorer. You are able to view the Primary Token of a process by right-clicking a process and looking at the Security tab. This displays the processes’ security context. If I execute runas /user:domainname\differentuser c:\windows\system32\notepad.exe from a prompt, I will see that this process is running under different user credentials.

    clip_image010

    Notice that the process tree appears to start in two places, System and Explorer. Explorer.exe is the root of the user shell environment and runs under the context of the logged on user. When we open most applications, they open as a process underneath Explorer and inherit the user token used by Explorer (with some exceptions that will be discussed in a future post.) As discussed earlier, this is how we continue using our logged on credentials when navigating through the Windows shell. Now look at the Notepad process running under alternate credentials. This is under its own SVChost.exe because it creates a process with a new logon session. You can right click on several of the services running under Services.exe and you will see credentials of the service startup account for each of the running services. These services do not inherit the token of the parent process, Services.exe, because it is a special process running as the local system that creates new processes with a new logon session.

    This ends our first post on tokens. In a future blog post we will look at how processes are able to impersonate other tokens. We will also explore several different ways the operating system can manipulate a token, such as restrictive, elevated, integrity levels and so-called “split” tokens used in Windows Vista.

    Cheers,

    Randy Turner

  • Configuring your PDCE with Alternate Time Sources

    Bob Drake from Microsoft again. Often we see situations where the forest root domain PDCE is configured to acquire time from a specified authoritative NTP source but cannot due to issues outside of the local network (IE: DNS, Routing). Typically the first signs of an issue are errors like Event ID 29:

    “The time provider NtpClient is configured to acquire time from one or more time sources; however none of the sources are currently accessible.  No attempt to contact a source will be made for 14 minutes. NtpClient has no source of accurate time.”

    This is because the computers cannot reach the NTP server.  What would be an easy resolution usually turns into unnecessary changes being made internally (usually registry configurations or topology) in attempts to fix the issue, making a bad situation worse. In an effort to avoid these scenarios there is a method to configure environments to have alternate NTP time server specified for fault tolerance to the W32Time service.  Let’s first see what the default settings are and how they work….

    Client settings

    • By default W32time is shipped with the operating system to point to “time.windows.com”.  This is true for both non-domain members and domain joined computers (as seen here from an XP client machine):

      image
    • Note the setting for “NT5DS”.  This setting means that the computer will follow the domain hierarchy and synchronize with a selected time source according to the time selection process as described here.

    Primary Domain Controller Emulator settings

    • Providing the PDCE has been properly configured with an NTP source according to the articles (2003)(2000)(XP) there will be a setting as shown:

      Note:  Any NTP Server can be configured, pictured is the default. Here is a list of NTP servers.

      image
       
    • This PDCE as shown is configured to use “time.windows.com” as its NTP source.  For an alternate NTP configuration we can modify the “NtpServer” key to reflect an additional peer after selecting one from a source of your choice. 

      clip_image002

    Note here we have selected “tick.usno.navy.mil” and have added/changed our flags according to the Windows Time Service Tools and Settings article:

    • 0x01 SpecialInterval
    • 0x02 UseAsFallbackOnly 
    • 0x04 SymmatricActive 
    • 0x08 Client

    By making the primary NTP server flag 0x9, we made it “Client 0x08 + SpecialInterval 0x01”  and as for the second NTP time server.

    By making the secondary NTP peer flag 0xa, we made it “0x08 Client + 0x02 UseAsFallbackOnly”.

    Now the PDCE has two sources to poll and acquire time from.  If we were to see issues here in the future, we can set up time debug logging from KB Article 816043 we would see the following in the w32time.log:

    SPECIAL NOTE HERE:  On initial sync during service startup the polling interval time is zero which will not match the special polling interval that our 0x01 flag requires. This being the case w32time will use the Fallback server as its primary choice until the special polling interval arrives then it will use the intended primary server. The specialpollinterval setting is discussed in KB Article 816042.

    In the referenced KB article the “FileLogName” has a path to point to “C:\Windows\Temp\w32time.log” but some may chose to log somewhere else like the common path “C:\Windows\Debug\w32time.log” . If done, it will never actually log anything. This is because the w32time.log will not write to the debug folder without modifying the debug folders’ permissions, so I recommend instead using the default (this should only be done for troubleshooting regardless, not turned on forever).

    • When the debug log is opened, the first section displays the configuration from the registry, and starts the providers (both client and server).  A little further down it will show the peers: 

      image

      Typically in a normal debug log, the machine then polls the NTP servers for time by sending a UDP NTP packet over port 123, and then gets samples from that server.  Once it has samples, it will choose the “best” sample based on the NTP algorithms and pass the chosen sample to the clock discipline for time adjustment.
    • Then our problem happens on the internet and we cannot reach “time.wndows.com” so we remove it as a peer:

      image 
    • Since we have configured and alternate, we can now poll our secondary peer “tick.usno.navy.mil” and synchronize from it:

      image

    So that’s it.  If the secondary NTP server was not configured prior to the real problem, an administrator could run into more complications by thinking the issue is internal and makes premature changes which might complicate things. Hopefully this helps you in the future!

    - Bob Drake