Hi,

I recently had the pleasure to help one of our Premier customers with a query they have regarding saving images in Active Directory.

Default Permission in AD

By default, users have permission to save a jpeg or bmp file to their own AD user account. This file can be up to 100KB in size. In a large AD with hundreds of thousands of users, this could quickly increase the size of the AD database. The increase in size can increase backup times, increase the backup size and slow down restores.

This permission is granted via the constructed security principal, “SELF”.

“SELF” is given permission to a set of attributes, not to the individual attributes themselves. By combining attributes into groups of common attributes, you reduce the size of the ACL entry. These groups are called Permission Sets. The attributes which relate to images are:

• Picture (aka thumbnailPhoto)
• jpegPhoto

The attribute Picture is in a Permission Set called Personal-Information. You can see the permission is applied to all users like this:

Control the Permission

They wanted to take away the permission for SELF to be able to write to the Picture attribute, but this shouldn’t be a high-level deny for Everyone to write to this attribute. It could be that some users somewhere at sometime need to write to this attribute.

What I suggested they do was de-couple the Picture attribute from the Property-Set called Personal-Information. Then apply an explicit permission to the root of the domain for a group which has write access to this attribute instead.

Unlink from a Property-Set

But how do you link (and therefore unlink) an attribute to a Property-Set?

The property sets are not found in the schema, but instead are found in the Configuration partition, under Extended-Rights.

Each of the Property Sets has an attribute identifying it, called rightsGuid. This GUID is used to pull in attributes as members of the property set by specifying the same GUID in the attribute of the attribute called attributeSecurityGUID. If these 2 GUIDs are the same, then the attribute will be a member of the Property Set. By removing the attributeSecurityGUID entry on the Picture attribute, it is no longer a member of the Personal-Information Property Set. And the SELF will lose permission to write to this attribute.

While this sounds very complicated, here’s a simple picture to explain it all:

The object on the left “CN=Personal-Information” is the property set. The object on the right “CN=Picture” is the attribute in the schema. It’s lDAPDisplayName is thumbnailPhoto. The attributes of these objects, rightsGuid and attributeSecurityGUID have the same value, a matching GUID.

Remove the GUID

When you remove the attributeSecurityGUID, open the attribute and click the button on the bottom left called “Clear”, as shown below:

Notice also that the text in the attribute editor isn’t the same as the text you see in the window behind. The characters appear as pairs and the pairs in the blocks have been switched around.

Undoing the Change

In order to restore the GUID if you change your mind, you need to copy the same form of the GUID from another attribute. I chose Post-Code as this is also in the Personal Information Permission Set.

I hope this helps someone else to delegate their Active Directory if needed.

Craig

Hi again,

Another interesting case with a nice, easy solution.

While working with a Premier customer recently we found that the 2 local groups relating to DHCP, “DHCP Administrators” and “DHCP Users” didn’t get created on their new DHCP servers.

Only the role installation steps can do this for us as that will make sure they were actually given the required rights to manipulate or view the service.

What to do?

We couldn’t just remove and reinstall the role – there was too much configuration already done.

We couldn’t ignore it as we were installing IPAM and it needs to place the IPAM servers computer account into the group “DHCP Users” on the servers. It does this by nesting itself into new a universal group in the domain: IPAMUG. This group is the one which actually becomes a member of the “DHCP Users” group.

The role was installed by a “next-next” manual installation using Server Manager. So it wasn’t as if some PowerShell or DISM.exe switch was accidentally left off. And if we repeated the manual installation, we would likely just end up where we started.

What went wrong?

At the end of the Server Manager wizard, you get this completion message (without the big red arrow, that’s my addition).

Inside there is a link to launch a wizard which will configure the DHCP server, called “Complete DHCP configuration”. This wizard does 2 things:

1. It creates the 2 groups we’re after: “DHCP Administrators” and “DHCP Users”
2. It authorizes the DHCP server in Active Directory if the DHCP server is joined to a domain

The authorization part is pretty nifty. Usually you do this by right-clicking on the server in the DHCP MMC console and selecting “Authorize”. This will create a object in the Configuration partition of the Active Forest under Services / NetServices for the DHCP server. Only members of Administrators in the forest root domain or members of Enterprise Admins can create objects here. The new wizard lets you type alternate credentials to do this job:

My customer had authorized their DHCP servers, by doing it the old way in the DHCP MMC console using an account with permission to do so.

They hadn’t noticed that small blue link from the image above. There is also a outstanding notification within any Server Manager console which connects to one of these DHCP servers (or on the local host itself). But that was also quiet subtle, and requires that you click on it to see the same blue link:

In fact, we hadn’t even noticed any of this by the time I’d found an alternative way of creating these groups on their DHCVP servers using netsh.exe:

netsh.exe dhcp add securitygroups

Had we run the wizard through to it’s completion, we would have got a success message like this stating that the local groups were successfully created:

I hope this helps someone avoid some troubleshooting time when deploying DHCP on Windows Server 2012.

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

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:

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.