A Premier Field Engineer in Denmark

MBAM 2.0 gets released along with Service Packs to most MDOP apps

Craig Forster — Fri, 12 Apr 2013 21:00:22 GMT

Hi,

Just a quick note to publicise that MBAM 2.0 is now out, and each of AGPM 4.0, DaRT8.0, App-v 5.0, UE-V 1.0 each received their own updates to Service Pack 1. They are bundled in the new MDOP 2013.

Read more about it here at the new home for the MDOP team: http://blogs.windows.com/windows/b/business/archive/2013/04/10/making-windows-8-even-more-manageable-with-mdop-2013.aspx

Using SONOS as a “Play To” destination from within Windows RT

Craig Forster — Mon, 08 Apr 2013 20:02:35 GMT

Hi,

I recently became the proud owner of the fantastic Sonos PLAYBAR. And while the Sonos team is considering creating a Windows 8 App to control their devices, I found a neat little hack to get the DLNA portion of the Sonos to become a “Play To” device from within Windows 8 music apps.

See the blog post here:

http://digitalmediaphile.com/index.php/2013/03/30/using-uncertified-play-to-devices-on-surface-rt-w8-apps/

Here are the registry keys I created for the PLAYBAR:

Troubleshooting Windows Performance Issues: Lots of RAM but no Available Memory

Craig Forster — Fri, 07 Dec 2012 10:14:49 GMT

Hi,

One of my recent posts was recently polished up enough to appear on the MSPFE blog:

http://blogs.technet.com/b/mspfe/archive/2012/12/06/lots-of-ram-but-no-available-memory.aspx

That blog roll is a new initiative within the Premier Field Engineer community to “put our best foot forward”.

Posts appear from all the Microsoft technologies we support by PFEs like me who are working everyday with our customers to help them to resolve their technical issues. I hope it’s useful to you.

Messages cannot be sent when Exchange Hub Transport Service runs as NetworkService

Craig Forster — Mon, 15 Oct 2012 12:38:20 GMT

Hi again,

I think the post title is pretty self explanatory.

Just to clarify it a little, the customer who hit this problem found that

A work-around was to run the service as LocalSystem.
Mails between mailboxes on the same server would not be delivered while running the Hub Transport service as NetworkService.
Those messages would move to the Sent Items folder in Outlook running in cached mode and would sit in Drafts and be shown in italics in OWA and Outlook in online mode.
Messages from the internet coming in would always be delivered just fine.

OK, so what could be causing the problem?

Well, let’s first define what the 3 built-in security contexts for running services are and how they differ from each other:

Account	Local Permissions	Can act on the network
LocalService	Limited	No
NetworkService	Limited	Yes
LocalSystem	Full	Yes

So any service running as LocalService cannot use the computers identity on the network and cannot authenticate to domain-joined resources on the network (and networked computers cannot authenticate to this service). A service running as NetworkService can do this authentication with remote resources. Both of these accounts have very limited permissions to access files and registry keys on the local system.

LocalSystem has no restrictions on the local computer and also has the ability to authenticate on the network and have networked computers authenticate with it. This is a bad context to use for the Hub Transport service as it has too much access on the local server.

So my first thought was that because LocalSystem works when sending messages and NetworkService does not work, then it wouldn’t be a problem regarding network authentication because both of these profiles support authenticating on the network. So it would be a local permission problem. Process Monitor from Sysinternals is a great tool for highlighting missing permissions to local resources.

We shutdown all but 1 Hub Transport servers and on the remaining Hub Transport server we started the Hub Transport service as NetworkService. We then started up Process Monitor with a filter to show only events where RESULT = ACCESS DENIED like this:

But when sending an email from one mailbox to another, it didn’t record any actions which were very interesting at all.

So, back to the drawing board. What about the scenario we excluded at the start? Network authentication. Well, what is happening with authentication is that the Mailbox server is trying to authenticate to the Hub Transport server to let it know that there are new messages that it needs to process.

To get started we need to know how it’s authenticating and are there any problems during authentication. We looked at the Security event logs on both the Mailbox server and the Hub Transport server focusing on the time the test message was sent. What we saw were “Audit Failure” with an Event ID 4265. The interesting parts of the event were that Kerberos was attempted, the SID authenticating was NULL and the error was “invalid key”.

We need to know which Kerberos tickets were in use for the LocalSystem logon session on the Mailbox server (we know that the information Store service starts as LocalSystem from here). We ran LogonSessions.exe from Sysinternals and got an output like this:

C:\>logonsessions.exe

Logonsesions v1.21
Copyright (C) 2004-2010 Bryce Cogswell and Mark Russinovich
Sysinternals - wwww.sysinternals.com

[0] Logon session 00000000:000003e7:
    User name:    CONTOSO\SERVER-1$
    Auth package: Negotiate
    Logon type:   (none)
    Session:      0
    Sid:          S-1-5-18
    Logon time:   10/10/2012 12:04:25
    Logon server:
    DNS Domain:   contoso.com
    UPN:          SERVER-1$@contoso.com

[1] Logon session 00000000:0000ae9f:
    User name:
    Auth package: NTLM
    Logon type:   (none)
    Session:      0
    Sid:          (none)
    Logon time:   10/10/2012 12:04:25
    Logon server:
    DNS Domain:
    UPN:

[2] Logon session 00000000:000003e4:
    User name:    CONTOSO\SERVER-1$
    Auth package: Negotiate
    Logon type:   Service
    Session:      0
    Sid:          S-1-5-20
    Logon time:   10/10/2012 12:04:26
    Logon server:
    DNS Domain:   contoso.com
    UPN:          CONTOS-1$@contoso.com

[3] Logon session 00000000:000003e5:
    User name:    NT AUTHORITY\LOCAL SERVICE
    Auth package: Negotiate
    Logon type:   Service
    Session:      0
    Sid:          S-1-5-19
    Logon time:   10/10/2012 12:04:26
    Logon server:
    DNS Domain:
    UPN:

The first entry [0] is LocalSystem using Kerberos. Next [1] is NTLM authentication. Then [2] is NetworkService and lastly [3] is LocalService which has no ability to authenticate. So the logon session ID we want to target is 0x3e7 which I’ve highlighted above.

We then ran klist tickets –li 0x3e7 on the Mailbox server to view the Kerberos service tickets held by the LocalSystem logon identity. This service will need a Kerberos ticket which is valid on the Hub Transport server. There was indeed a service ticket which was valid on the Hub Transport server (i.e. the encryption type AES256) was relevant as all Exchange servers are running on Windows Server 2008 SP2, the valid date range was correct and the clocks were in sync. So everything looks OK and the Mailbox server should be able to authenticate with the NetworkService logon session on the Hub Transport server. But it can’t. Why? Because the key which NetworkService on the Hub Transport servers should have been able to use to decrypt the incoming authentication message (the Kerberos service ticket) from the Mailbox server was broken for NetworkService, as explained here:

http://support.microsoft.com/kb/2566059

The domain functional level was at Windows Server 2003 and there was 1 2003 DC remaining in the domain, meaning that the pre-authentication key is encrypted using RC4 as newer AES128 and AES256 are not understood by 2003 DCs. When the first Windows Server 2008 member servers were added, they were these Exchange 2007 servers. The 2003 DCs started logging errors each time one of these 2008 clients requested a TGT or a Service Ticket because they would request it as AES256, which the 2003 OS didn’t understand. It would then negotiate down to RC4 and just work. In the mean time the 2003 DCs logged an error in the System event log about not understanding AES256.

As a workaround to prevent the errors from filling the event logs on the 2003 DCs and from filling the monitoring application window, they implemented a reg key on the Exchange servers to force them to always request RC4 encrypted tickets. They found this hint on a 3rd party user forum site.

We removed this key on the Mailbox servers:

HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\DefaultEncryptionType

We then removed all the Kerberos tickets which were cached on the Mailbox server using this command:

klist purge –li 0x3e7

And we then verified that this hotfix was installed on the remaining 2003 DCs so that they wouldn’t log the errors which flooded the event viewer causing them to implement the key we removed:

http://support.microsoft.com/kb/948963

We couldn’t install the hotfix mentioned in KB2566059 on the Mailbox servers as they were running on Windows Server 2008 SP2 and the hotfix was only built and released for Windows Server 2008 R2 as was not back-ported to Windows Server 2008 SP2. So the hotfix was not available to us.

As a final note, why did internet messages work? Well, those messages are coming from unauthenticated senders – on the internet. Messages travelling from one mailbox to another are coming from one authenticated user to another. So authentication must be working for mailbox-to-mailbox messaging. But unauthenticated messages from the internet just worked.

I hope this helps someone else in their troubleshooting the future.

SharePoint and SID History not playing well together

Craig Forster — Mon, 15 Oct 2012 10:41:44 GMT

Hi,

I struck a problem at a custom and the impact, while it seemed minor on the surface, was actually a big deal for their migration project. In fact, the large team they had assembled to migrate users from one forest to a new forest had stopped while this issue was investigated.

It relates to SID History and the way Windows queries for and caches Name-to-SID and SID-to-Name lookups from AD. This cache was causing SharePoint to think that a user who wanted to logon was actually a user from the wrong domain, and would create that person a new identity for that person within SharePoint for them.

The scenario is actually very close to this one:

http://blogs.technet.com/b/rgullick/archive/2010/05/15/sharepoint-people-picker.aspx

But the workaround that we found would resolve the problem while they were migrating was pretty cool, so I thought I’d save it for all eternity here as a blog.

It boils down to this:

The LsaCache stores the previously looked-up domain user names and their SIDs. By asking a DC which has users that have both the new SID and the migrated SID on them at the same time, the DC always links the migrated SID to the new user name, not the old user name. If we can artificially fill the LsaCache with mappings for OLD USERNAME = OLD SID in our servers, then we can act as though no resources have migrated yet.

Here’s the scenario where users were migrated with SID History from child1.domainA.com to domainB.com

CHILD1\bob logs onto a workstation in CHILD1 and opens the SPS site in DOMAINB (intranet.domainB.com)
SPS asks IIS, which asks Windows for a local DC to resolve a remote SID: S-1-5-21-[SID_for_CHILD1]-1010
The local DC finds the SID assigned to the migrated user in the global catalog
The local DC returns the account name of the migrated user, DOMAIN2\bob
The SPS server adds the result to its LsaCache as a mapping for this SID to the DOMAIN2 account

So we can see from the picture above that the LsaCache (the table in the bottom right of the drawing) has a mapping for NEW USERNAME = OLD SID but we want OLD USERNAME = OLD SID

So, let’s warm up the LsaCache so it looks the way we’d like it to:

SPS constantly runs a script to query for the name CHILD1\bob
The local DC queries its Global Catalog and does NOT have a record for this username
The local DC must do its own LSA query to a DC in the domain CHILD1 for this name
The remote DC in CHILD1 finds the user and replies with the SID: S-1-5-21-[SID_for_CHILD1]-1010
The CHILD1 DC returns this to the DOMAINB DC (the DOMAINB DC caches this result in its own LsaCache)
The local DC returns this result to the SPS server
The SPS server adds this entry to its LsaCache

Ah ha! Now our cache looks the way we’d like it, where OLD USERNAME = OLD SID. This way when a query for OLD SID is made, the result from cache will return OLD USERNAME.

CHILD1\bob logs onto a workstation in CHILD1 and opens the SPS site in DOMIANB (intranet.domainB.com)
SPS does NOT ask the local DC for the remote SID, it uses its LsaCache
The LsaCache on SPS replies back with the username which relates to the SID: S-1-5-21-[SID_for_CHILD1]-1010 is CHILD1\bob

The important step here is the red X where there IS NO STEP. What I mean is that the SharePoint server never talked to the DC to get the OLD SID lookup to return a result, meaning that we relied totally on the warmed up cache on the SPS alone.

This relies on the LsaCache on the SPS server ALWAYS having the entry for the SID from the CHILD1 domain matching the CHILD1 username, and never matching the DOMAINB username. The only way to ensure this is:

Constantly query from the SPS server for the name CHILD1\username for every user in DOMAINB which has been migrated from CHILD1 and has its SIDHistory migrated with it. Use a tool which invokes LookupAccountName() to locate the SID for the username: CHILD1\username. LookupAccountName is explained here: http://msdn.microsoft.com/en-us/library/aa379159(v=vs.85). I had access to a private tool which would do these queries for us. I suspect that PsGetSid from Sysinternals would be able to help out here too, but we never tried it.
The LsaCache on SPS must be large enough to sure that the entries which are queried are never overwritten by entries from DOMAINB. Set the reg value HKLM\System\CurrentControlSet\Contol\Lsa\LsaLookupCacheMaxSize = (DWORD) = 0x2000 (8192 decimal). If this value does not exist the system uses a default cache size of 128 entries, which is overwritten too quickly on the busy SPS servers. 8192 entries on a pair of load balanced servers should be able to hold all SIDs for all users accessing the SPS site in the 2 forests (if your forest has more users, you’ll need to increase this.
This is a workaround. The real fix is to have the users who are migrated from CHILD1.domain.com to domainB.com with SIDHistory should use their migrated accounts immediately. After the migration, their CHILD1 accounts should be disabled/deleted and SIDHistory should be removed from the DOMAINB accounts. This is an operationally very difficult action to do as it does not allow for an easy testing path or roll-back path.

To view the actions as they are performed by LSA Lookups, add these 2 DWORDs to the registry under HKLM\System\CurrentControlSet\Control\Lsa\:

LspDbgTraceOptions = 0x1 (1 means “log to a file”, the file is C:\Windows\Debug\Lsp.log)
LspDbgInfoLevel = 0x88888888 (all 8‘s in hex means “log as verbose as possible”)

These keys are explained here:

http://technet.microsoft.com/en-us/library/ff428139(v=ws.10).aspx

So, all in all a little complicated, but the workaround to increase the value for LsaLookupCacheMaxSize and constantly running a script on the SPS server to query for the SID for usernames in CHILD1 (with a filter to target only users which had been migrated to domainB) worked well for the customer.

Upgrading the ADMX Central Store files from Windows 7/2008R2 to Windows 8/2012

Craig Forster — Mon, 27 Aug 2012 22:03:00 GMT

##############################

### UPDATE (22 March 2013) ###

The ADMX and ADML files for Windows 8 and Windows Server 2012 are now available as a separate download. This includes 185 ADMX files, and is the complete set of all ADMX files for these OSes. Please use this download instead of the instructions in this post to create your super-set of updated ADMX/ADML files.

http://www.microsoft.com/en-us/download/details.aspx?id=36991

##############################

Hi,

A while back I posted something similar regarding upgrading the PolicyDefinitions folder in SYSVOL from Windows Vista and Windows Server 2008 set of ADMX/ADML files to their newer versions in Windows 7 and Windows Server 2008 R2. That post is here.

Well, it’s now time to move that on as Windows 8 and Windows Server 2012 are now out.

First off, all ADMX/ADML files have had their dates updated. While I didn’t look to see if all the contents of the files have changed, it’s probably best to assume every file has changed and update all of them.

One of them "(“InputPersonalization.admx”) has been removed since Windows 7. It controlled 1 setting, and this setting has been moved into the larger ControlPanel.admx. Meaning this admx/adml can be deleted once the newer ControlPanel.admx file is copied to the PolicyDefinitions folder.

Windows 8 and Windows Server 2012 offer a range of new features (he says putting it mildly), and there are new admx/adml files for these. So make sure you include these in your update

ADMX/ADML files new in Windows 8 and Windows Server 2012

AppxPackageManager.admx
AppXRuntime.admx
DeviceCompat.admx
DeviceSetup.admx
EAIME.admx
EdgeUI.admx
EncryptFilesonMove.admx
FileServerVSSAgent.admx
FileServerVSSProvider.admx
hotspotauth.admx
LocationProviderAdm.admx
msched.admx
NCSI.admx
NetworkIsolation.admx
Printing2.admx
Servicing.admx
SettingSync.admx
srm-fci.admx
StartMenu.admx
WCM.admx
WinStoreUI.admx
wlansvc.admx
WPN.admx
wwansvc.admx

As with the previous operating systems, there are some admx/adml files which exist on the server SKU which do not also exist on the client SKU, and vice versa:

ADMX/ADML files which exist on Windows Server 2012 but do NOT exist on Windows 8

adfs.admx
FileServerVSSAgent.admx
GroupPolicy-Server.admx
MMCSnapIns2.admx
NAPXPQec.admx
PswdSync.admx
Snis.admx
TerminalServer-Server.admx
WindowsServer.admx

ADMX/ADML files which exist on Windows 8 but do NOT exist on Windows Server 2012

DeviceRedirection.admx
sdiagschd.admx

And the easy way to get all the possible ADMX/ADML files for a particular OS without having to install all the roles/features is to simply copy them out of the winsxs directory (replace en-US in the commands below if your OS is installed in a language other than English). Here is a sample set of commands which can do this for you. You’d need to run this on both a Windows 8 and Windows Server 2012 computers to capture all possible admx/adml files.

cd /d %windir%\winsxs
dir *.admx /s /b > %USERPROFILE%\Desktop\admx.txt
dir *.adml /s /b | find /i "en-us" > %USERPROFILE%\Desktop\adml_en-us.txt

mkdir %USERPROFILE%\Desktop\PolicyDefinitions
mkdir %USERPROFILE%\Desktop\PolicyDefinitions\en-US
FOR /F %i IN (%USERPROFILE%\Desktop\admx.txt) DO copy %i %USERPROFILE%\Desktop\PolicyDefinitions\
FOR /F %i IN (%USERPROFILE%\Desktop\adml_en-us.txt) DO copy %i %USERPROFILE%\Desktop\PolicyDefinitions\en-US\

I hope that helps you with your admx/adml upgrade.

Craig

Using Delegation in Scheduled Tasks

Craig Forster — Tue, 15 Mar 2011 10:59:25 GMT

This blog is about the ability in Windows 7 and Windows Server 2008 R2 to apply a SID to every scheduled task and use that SID to apply permissions elsewhere in the Operating System.

Services already have this feature from Vista and newer. The idea is the same; take the simple name for the service (or in that case of scheduled tasks in 7/R2 the path to the scheduled task) and compute a predictable SID based on that name. Have a look at the permissions applied to C:\Windows\System32\LogFiles\Firewall to see this in action. On the permissions of this folder, there is an ACE for a “group” called MpsSvc, which is the short name for the Windows Firewall service. In this way, even though the service is set to start as “Local Service”, not all other services which also run as this same account can see into the Firewall logs, only the firewall service itself has access.

So every scheduled task can have a SID computed for it – this new feature is described here:

http://msdn.microsoft.com/en-us/library/ee695875(v=vs.85).aspx

And the way to locate what the predicable SID for a given service name is to run:

schtasks /showsid /TN “TaskName”

With this SID, you can now assign permissions to resources. For example, you could use icacls to apply permission to a folder, below we are granting an NT TASK (SID starts with S-1-5-87) modify permission to the folder C:\SomeFolder:

icacls C:\SomeFolder /grant *S-1-5-87-xxxx-yyyy-zzzz:(M)

Now, if you go and setup your task in the GUI, and run these commands, you will see icacls report back:

No mapping between account names and security IDs was done.

What went wrong?

First you need to make sure that the scheduled task is configured for Windows 7 or Windows Server 2008 R2 and is using either “Network Service” or “Local Service”:

Then you need to make the task use the Unified Scheduling Engine so that it registers the SID with the list of “well known SIDs” for the system. But there is no check-box for this setting, and it is disabled by default. What to do?

Export your task as an XML file, locate the line which reads:

<UseUnifiedSchedulingEngine>False</UseUnifiedSchedulingEngine>

And change that “False” to “True”:

<UseUnifiedSchedulingEngine>True</UseUnifiedSchedulingEngine>

With that changed, remove your task and import the XML file you modified above.

Because the SID is a predicable calculation of the path to the task, so long as you recreate the task with the same name and in the same folder, the SID will remain the same and your icacls command will now work as expected, and only that scheduled task will have access to the file or folder to specify.

The Unified Scheduling Engine leverages the Unified Background Process Manager (UBPM), which is described further here:

http://blogs.technet.com/b/askperf/archive/2009/10/04/windows-7-windows-server-2008-r2-unified-background-process-manager-ubpm.aspx

Getting error 0xC004F074 when activating against KMS server

Craig Forster — Thu, 03 Mar 2011 09:43:44 GMT

This error code is a very generic output to a KMS client having problems activating. To view your output, run slmgr.vbs –ato

When troubleshooting this problem, we checked the following details – if any were a problem, they would generate this error code:

DNS record not published at _VLMCS._tcp.client.domain. This must be an SRV record, which the KMS server will automatically register. If you have disabled this, you will need to use a GPO on the clients to point them to the correct KMS server to use
No network connectivity from the KMS client to the MS server on the KMS port (tcp/1688 by default). Install telnet on the client and run telnet KMS.Server.Name 1688 and make sure the screen goes blank
Not more than 4 hours time difference between KMS server and client. Check that your time zones are correct. If using server core, run timedate.cpl
No major hardware changes to the KMS server. If the KMS server is a VM and you have added a number of new devices, CPUs, memory etc, or P2Ved you will need to reactivate your KMS license
The KMS service must have the keys to issue for the KMS client requesting a license. For example, if the KMS server is Windows Server 2008 and you are trying to activate Windows 7, you will need an update installed on the KMS server AND the correct KMS key for Windows 7.

And the last one was the problem we hit: Our KMS server was Windows Server 2008 R2, just as the KMS clients. We’d crossed the threshold of 5 servers. But they still would not activate. The problem was that there are different license “channels” for Windows Server. They are described here: http://technet.microsoft.com/en-us/library/ff793411.aspx

Our servers which were having problems activating were all Windows Server 2008 R2 Datacenter Edition, and we had a “B Channel” KMS license installed on the KMS server.

We followed these steps on the KMS server to install the correct channel license:

slmgr -upk
slmgr -cpky
slmgr -ipk <KMS Host Product Key - channel C>
slmgr -ato

After doing the above, we ran slmgr -ato on the Windows Server 2008 R2 Datacenter Edition servers. Note that “Channel C” is able to active all lower level channels.

Cannot bring Cluster Name resource online

Craig Forster — Fri, 04 Feb 2011 10:06:41 GMT

Hi,

Another quick post with a non-very-obvious solution, this time on a new Windows Server 2008 R2 cluster.

The case went like this:

The OSes of the nodes were built according to the security requirements of the customer
We added the Failover Clustering feature and attempted to create a new cluster while running the wizard as a member of Domain Admins who has Administrator permissions on all the nodes
The computer account in the domain was created for the Cluster Name Object (CNO), the account ‘SELF’ had full control
The wizard completed fine and the summary report showed no problems
The Cluster Name resource couldn’t come online
On the nodes the event ID 1206 was logged, which said:
- Cluster network name resource 'Cluster Name' cannot be brought online. The computer object associated with the resource could not be updated in domain 'domain.name'. The error code was 'Unable to find computer account on DC where it was created'. The cluster identity 'CLUSTER01$' may lack permissions required to update the object. Please work with your domain administrator to ensure that the cluster identity can update computer objects in the domain
More confusing still, in the security log of the DC, there were “Kerberos pre-authentication failed” errors for the CNOs computer account, indicating that the wrong password was being used

The problem turned out to be that the built-in group “Authenticated Users” had been removed from the built-in group “Users” on the OS of each of the nodes. The customer didn’t want to add “Authenticated Users” back into this group as that would have granted too many accounts too many rights. The work-around we put in was to create a domain group and nest the newly created CNO into this group. This group was placed into the “Users” built in group on all the cluster nodes. In this way, the CNO now has membership in the built-in group “Users” on each of the nodes.

We needed to reboot all of the nodes before this change would take effect.

I hope this helps someone out there.

Delegating access in AD to BitLocker recovery information

Craig Forster — Wed, 26 Jan 2011 10:31:00 GMT

Normally in AD, all attributes are readable by “Authenticated Users”. Some attributes should inherit permissions, but should not be readable by “just anyone” To protect attributes like this, they can be marked as “confidential”.

There are 3 attributes relating BitLocker to which are marked in the schema as “confidential”.

This is done by marking the searchFlags attribute as enabled for bit 7 (128 decimal) in the schema where the attribute is defined. See here for more information on searchFlags: http://support.microsoft.com/kb/922836

These attributes are:

Attribute	Applies to Object	Used for
msTPM-OwnerInformation	computer	Contains the owner information of a computers TPM.
msFVE-KeyPackage	msFVE-RecoveryInformation	Contains a volumes BitLocker encryption key secured by the corresponding recovery password.
msFVE-RecoveryPassword	msFVE-RecoveryInformation	Contains a password that can recover a BitLocker-encrypted volume.

An object of type “msFVE-RecoveryInformation” is created for every encrypted volume and is stored as a sub-object of the computers object where the volume was encrypted.

Simply granting “read” access to these attributes will not allow a user to read the information in these attributes. A user who wants to read the attribute must also have an Access Mask for “Control_Access”. This is a special type of ACE (Access Control Entry). See here for more information on Access Masks: http://msdn.microsoft.com/en-us/library/aa374896(v=vs.85).aspx

GUI Tool to Manage Permissions

The only GUI tool which can set and view these special Control_Access ACEs is LDP.exe (using the version from Windows Server 2003 R2 ADAM or newer). This is shown below:

The "Control_Access" flag is needed in ADDITION to the normal "Read Propery" right. The "Control_Access" flag gets you past the confidentiality bit. You still need to be able to read the contents of the attribute.

Apply the permission once at the top of EACH DOMAIN where you need to delegate access to the recovery information of BitLocker volumes. Usually this does not include forest root domains or resource forests. Ensure the “inheritance” box is checked on each ACE so that it propagates to every msFVE-RecoveryInformation or Computer object and only to its relevant attributes.

(Note from Ryans comment below: You can aply this permission anywhere in the OU structure if you'd like to split the delegation bewteen groups - e.g. Help Desk users can access the keys for Standard Workstations and the Server Admins can access the keys for servers etc. You could apply the "read propery" ACE at the top of the domain to a super-group for everyone who is allowed to access the keys, and then have different groups able to use the "Control_Access" flags for their particular OUs. This will help limit ACE bloat in lsass.exe working set while still locking down the keys in the way you'd expect.)

Here are sample scripts to add the "Control_Access" flag to the top of the domain:

DelegateBitLocker.vbs

Taken from: http://technet.microsoft.com/en-us/library/cc771778(WS.10).aspx

'To refer to other groups, change the group name (ex: change to "DOMAIN\Help Desk Staff")

strGroupName = "BitLocker Recoverers"

' -----------------------------------------------------------

' Access Control Entry (ACE) constants

' -----------------------------------------------------------

'- From the ADS_ACETYPE_ENUM enumeration

Const ADS_ACETYPE_ACCESS_ALLOWED_OBJECT = &H5 'Allows an object to do something

'- From the ADS_ACEFLAG_ENUM enumeration

Const ADS_ACEFLAG_INHERIT_ACE = &H2 'ACE applies to target and inherited child objects

Const ADS_ACEFLAG_INHERIT_ONLY_ACE = &H8 'ACE does NOT apply to target (parent) object

'- From the ADS_RIGHTS_ENUM enumeration

Const ADS_RIGHT_DS_CONTROL_ACCESS = &H100 'The right to view confidential attributes

Const ADS_RIGHT_DS_READ_PROP = &H10 ' The right to read attribute values

'- From the ADS_FLAGTYPE_ENUM enumeration

Const ADS_FLAG_OBJECT_TYPE_PRESENT = &H1 'Target object type is present in the ACE

Const ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT = &H2 'Target inherited object type is present in the ACE

' -----------------------------------------------------------

' BitLocker schema object GUID's

' -----------------------------------------------------------

'- ms-FVE-RecoveryInformation object:

' includes the BitLocker recovery password and key package attributes

SCHEMA_GUID_MS_FVE_RECOVERYINFORMATION = "{EA715D30-8F53-40D0-BD1E-6109186D782C}"

'- ms-FVE-RecoveryPassword attribute: 48-digit numerical password

SCHEMA_GUID_MS_FVE_RECOVERYPASSWORD = "{43061AC1-C8AD-4CCC-B785-2BFAC20FC60A}"

'- ms-FVE-KeyPackage attribute: binary package for repairing damages

SCHEMA_GUID_MS_FVE_KEYPACKAGE = "{1FD55EA8-88A7-47DC-8129-0DAA97186A54}"

'- Computer object

SCHEMA_GUID_COMPUTER = "{BF967A86-0DE6-11D0-A285-00AA003049E2}"

'Reference: "Platform SDK: Active Directory Schema"

' -----------------------------------------------------------

' Set up the ACE to allow reading of all BitLocker recovery information properties

' -----------------------------------------------------------

Set objAce1 = createObject("AccessControlEntry")

objAce1.AceFlags = ADS_ACEFLAG_INHERIT_ACE + ADS_ACEFLAG_INHERIT_ONLY_ACE

objAce1.AceType = ADS_ACETYPE_ACCESS_ALLOWED_OBJECT

objAce1.Flags = ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT

objAce1.Trustee = strGroupName

objAce1.AccessMask = ADS_RIGHT_DS_CONTROL_ACCESS + ADS_RIGHT_DS_READ_PROP

objAce1.InheritedObjectType = SCHEMA_GUID_MS_FVE_RECOVERYINFORMATION

' Note: ObjectType is left blank above to allow reading of all properties

' -----------------------------------------------------------

' Connect to Discretional ACL (DACL) for domain object

' -----------------------------------------------------------

Set objRootLDAP = GetObject("LDAP://rootDSE")

strPathToDomain = "LDAP://" & objRootLDAP.Get("defaultNamingContext") ' e.g. string dc=fabrikam,dc=com

Set objDomain = GetObject(strPathToDomain)

WScript.Echo "Accessing object: " + objDomain.Get("distinguishedName")

Set objDescriptor = objDomain.Get("ntSecurityDescriptor")

Set objDacl = objDescriptor.DiscretionaryAcl

' -----------------------------------------------------------

' Add the ACEs to the Discretionary ACL (DACL) and set the DACL

' -----------------------------------------------------------

objDacl.AddAce objAce1

objDescriptor.DiscretionaryAcl = objDacl

objDomain.Put "ntSecurityDescriptor", Array(objDescriptor)

objDomain.SetInfo

WScript.Echo "SUCCESS!"

DelegateTMPOwners.vbs

Taken from: http://technet.microsoft.com/en-us/library/cc771778(WS.10).aspx

'To refer to other groups, change the group name (ex: change to "DOMAIN\TPM Owners")

strGroupName = "TPM Owners"

' ------------------------------------------------------------

' Access Control Entry (ACE) constants

' ------------------------------------------------------------

'- From the ADS_ACETYPE_ENUM enumeration

Const ADS_ACETYPE_ACCESS_ALLOWED_OBJECT = &H5 'Allows an object to do something

'- From the ADS_ACEFLAG_ENUM enumeration

Const ADS_ACEFLAG_INHERIT_ACE = &H2 'ACE applies to target and inherited child objects

Const ADS_ACEFLAG_INHERIT_ONLY_ACE = &H8 'ACE does NOT apply to target (parent) object

'- From the ADS_RIGHTS_ENUM enumeration

Const ADS_RIGHT_DS_CONTROL_ACCESS = &H100 'The right to view confidential attributes

Const ADS_RIGHT_DS_READ_PROP = &H10 ' The right to read attribute values

'- From the ADS_FLAGTYPE_ENUM enumeration

Const ADS_FLAG_OBJECT_TYPE_PRESENT = &H1 'Target object type is present in the ACE

Const ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT = &H2 'Target inherited object type is present in the ACE

' ------------------------------------------------------------

' TPM and FVE schema object GUID's

' ------------------------------------------------------------

'- ms-TPM-OwnerInformation attribute: SHA-1 hash of the TPM owner password

SCHEMA_GUID_MS_TPM_OWNERINFORMATION = "{AA4E1A6D-550D-4E05-8C35-4AFCB917A9FE}"

'- Computer object

SCHEMA_GUID_COMPUTER = "{BF967A86-0DE6-11D0-A285-00AA003049E2}"

'Reference: "Platform SDK: Active Directory Schema"

' ------------------------------------------------------------

' Set up the ACE to allow reading of TPM owner information

' ------------------------------------------------------------

Set objAce1 = createObject("AccessControlEntry")

objAce1.AceFlags = ADS_ACEFLAG_INHERIT_ACE + ADS_ACEFLAG_INHERIT_ONLY_ACE

objAce1.AceType = ADS_ACETYPE_ACCESS_ALLOWED_OBJECT

objAce1.Flags = ADS_FLAG_OBJECT_TYPE_PRESENT + ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT

objAce1.Trustee = strGroupName

objAce1.AccessMask = ADS_RIGHT_DS_CONTROL_ACCESS + ADS_RIGHT_DS_READ_PROP

objAce1.ObjectType = SCHEMA_GUID_MS_TPM_OWNERINFORMATION

objAce1.InheritedObjectType = SCHEMA_GUID_COMPUTER

' ------------------------------------------------------------

' Connect to Discretional ACL (DACL) for domain object

' ------------------------------------------------------------

Set objRootLDAP = GetObject("LDAP://rootDSE")

strPathToDomain = "LDAP://" & objRootLDAP.Get("defaultNamingContext") ' e.g. string dc=fabrikam,dc=com

Set objDomain = GetObject(strPathToDomain)

WScript.Echo "Accessing object: " + objDomain.Get("distinguishedName")

Set objDescriptor = objDomain.Get("ntSecurityDescriptor")

Set objDacl = objDescriptor.DiscretionaryAcl

' ------------------------------------------------------------

' Add the ACEs to the Discretionary ACL (DACL) and set the DACL

' ------------------------------------------------------------

objDacl.AddAce objAce1

objDescriptor.DiscretionaryAcl = objDacl

objDomain.Put "ntSecurityDescriptor", Array(objDescriptor)

objDomain.SetInfo

WScript.Echo "SUCCESS!"

And this script can help pull the assigned ACEs out to show you who has been delegated access: http://gallery.technet.microsoft.com/ScriptCenter/0bd4af9e-968a-4ae6-9950-2b2450afda37/

A Premier Field Engineer in Denmark

MBAM 2.0 gets released along with Service Packs to most MDOP apps

Using SONOS as a “Play To” destination from within Windows RT

Troubleshooting Windows Performance Issues: Lots of RAM but no Available Memory

Messages cannot be sent when Exchange Hub Transport Service runs as NetworkService

Account

Local

Permissions

Can act

on the network

SharePoint and SID History not playing well together

Upgrading the ADMX Central Store files from Windows 7/2008R2 to Windows 8/2012

ADMX/ADML files new in Windows 8 and Windows Server 2012

ADMX/ADML files which exist on Windows Server 2012 but do NOT exist on Windows 8

ADMX/ADML files which exist on Windows 8 but do NOT exist on Windows Server 2012

Using Delegation in Scheduled Tasks

Getting error 0xC004F074 when activating against KMS server

Cannot bring Cluster Name resource online

Delegating access in AD to BitLocker recovery information

GUI Tool to Manage Permissions

DelegateBitLocker.vbs

DelegateTMPOwners.vbs