One of the things I never really noticed is the change in the behavior of the Shift Lock keys over the years. Somewhere it seems to have changed. I use it very rarely, but some users do. The complaint we received was that in the past they could just tap shift and it would unlock the shift lock, whilst now they really had to touch the shift lock again. Well it seems it’s actually pretty easy modify this behavior:

Open the Region and Language section in the control panel, choose they Keyboards and Languages tab and then click Change keyboards

Now pick the Advanced Key Settings tab:

Source: How to turn off the CAPS LOCK key

I’m currently facing an issue I had some issues in the past with an ADFS deployment using ISA as an ADFS Proxy. We use ISA for the following reasons:

• It allows us to do all kinds of authentication. For instance we are using BE-ID to authenticate users.
• The customer already has ISA so we save out a server by not using the ADFS Proxy itself.
• There’s no federation with other IDPs so we don’t have to do any fancy home realm discovery.

Now the problem we were seeing was that whenever the ISA session timed out, the user was presented with the ISA Forms Based Authentication (FBA) logon screen. If the users were to choose another identity, he would still appear as the original user towards the ADFS enabled application.

This makes totally sense as the client also got ADFS tokens and they have other timeouts than those configured on ISA. This post will try to explain some relevant parameters from the ADFS side. I’m not saying the defaults aren’t good, that’s something you’ve got to decide for yourself.

WebSSOLifetime (Default 480 = 8 hours)

This parameter is server-wide. Meaning if you configure it, it’s active for all of the ADFS relying parties. Whenever a user asks a token for a given RP he will have to authenticate to the ADFS service first. Upon communicating with the ADFS service he will receive two tokens: a token which proves who he is (let’s call that the ADFS Token) and a token for the RP (let’s say the RP Token). All in all this seems very much like the TGT and TGS tickets of Kerberos.

Now the WebSSOLifetime timeout determines how long the ADFS token can be used to request new RP Tokens without having to re-authenticate. In other words a user can ask new tokens for this RP, or for other RP’s, and he will not have to prove who he is until the WebSSOLifetime expires the ADFS token.

TokenLifetime (Default 0 (which is 10 hours))

The TokeLifetime is now easy to explain. This parameter is configurable for each RP. Whenever a user receives a RP Token, it will expire at some time. At that time the user will have to go to the ADFS server again an request a new RP token. Depending on whether or not the ADFS Token is still valid or not, he will not have to re-authenticate.

One argument to lower the TokenLifetime could be that you want the claims to be updated faster. With the default whenever some of the Attribute Store info is modified, it might potentially take 10 hours before this change reaches the user in its claims.

I wrote this post because I struggled with this myself and I found not that much information. There’s some information available in the SharePoint 2010 context, but I feel like these parameters aren’t explained enough. I have to admit that the above came clear once I saw one of the ADFS sessions at The Experts Conference of Laura E. Hunter and Brian Puhl. Thanks both for your great sessions!

One of the problems with delegating permissions for a file system or Active Directory objects is the fact that the creator of the object is also the owner of an object.

Suppose you got someone who is a member of a group which grants him permission to create objects. This delegation would set the user who created the object as the owner of that object. Because he’s the owner he has full control regardless the delegation which is configured. Now suppose this person is removed from the group for one reason or another. In that case that person still has full control on the object he created because he is “owner”!...

This is where owner rights come in. You can restrict what permissions you get when you are the owner of the object. At my customers site this was configured to be just “read”. The owner rights principal is something from Windows 2008 and onwards. So when you are member of the group which got delegated permission you got: delegated to group permissions + owner right permissions = full control + read.
However once you are removed from the delegated group you have owner right permissions = read

Here’s some info from TechNet: http://technet.microsoft.com/en-us/library/dd125370(WS.10).aspx

How did we apply it in our environment?:

Added the “Owner Rights” entry with the following SACL on some top level OU’s: “Read (List Contents, Read all properties, Read permissions)” on “this object and all descendent objects”

So how does Exchange ActiveSync (EAS) comes into play? Well we seemed to have issues when user wanted to configure their device. They’d Always seem to end up with an error. On the CAS server we had the following error:

Log Name: Application

Source: MSExchange ActiveSync
EventID: 1053

Exchange ActiveSync doesn't have sufficient permissions to create the "<user object distinguished name>" container under Active Directory user "Active Directory operation failed on <Domain Controller FQDN>. This error is not retriable. Additional information: Access is denied. Active directory response: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 ". Make sure the user has inherited permission granted to domain\Exchange Servers to allow List, Create child, Delete child of object type "msExchangeActiveSyncDevices" and doesn't have any deny permissions that block such operations

I don’t have the time right now to go deeper into the troubleshooting process and the solution. In short this is what we noticed and what we did:

Whenever a user tries to configured an ActiveSync device, an object is created in Active Directory below the user object. More specifically a msExchActiveSyncDevices container object. And below this one an object is created for each device configured with ActiveSync.

• User [e.g. JohnDoe001]
• msExchActiveSyncDevices [container]
• msExchActiveSyncDevice [device#1]
• msExchActiveSyncDevice [Device#2]

The problem here is that the security for a newly created msExchActiveSyncDevices object is not correct. The Exchange schema prep should add the Exchange Servers with some permissions. In an environment without the Owner Rights configured everything works as the Exchange Servers are also the owners of these objects and thus have full control permissions.

The following procedure was performed so that we could leave the Owner Rights in place

1. Right-click the domain root and choose properties. Open the security tab:
2. Advanced => Add
3. Select the “Exchange Servers” principal
4. Check the permissions as shown in the screenshot:
• List contents
• Read all properties
• Write all properties
• Read Permissoins
• Modify Permissions
• Modify Owner

Make sure to select “Descendant msExchActiveSyncDevices” in the Apply to section.

Recently we installed the KB (KB958830) which adds the Remote Server Administration Tools (RSAT) to a Windows 7 computer. Installing this KB is a two step process: first you install the bits, afterwards you enable the required tools in the Turn Windows features on or off section of the Windows Configuration Panel.

In our case adding tools like Active Directory Users & Computers (ADUC) went fine, but we were unable to add the Active Directory Administrative Center:

Clicking OK starts the configuration of the selected components:

Which finally result in:

In words: An error has occurred. Not all of the features were successfully changed.This is followed by a prompt to restart the computer. In my case I ignored this. After some googling I started suspected are favorite trouble-causer: Antivirus. So I started the McAfee console as an Administrator, unlocked the interface and disabled the On Access Scanner. Remark: in order to do so you first need to stop the Access Protection.

And now I could check the Active Directory Administrative Center and the configuration finishes gracefully… Probably some exclusion would fix this for good, however for now I lack time to dig deeper…

Also related, in the Event Log, below the Setup section, I found the following event entry:

Update RemoteServerAdministrationTools-Roles-AD-DS-AdministrativeCenter of package KB958830 failed to be turned on. Status: 0x80070643.

Perhaps this might help people finding this post faster.