Monthly Archives: December 2014

Customizing DirSync Installs

The majority of companies I work with who utilize an Office365 service will utilize the DirSync service at least for password synchronization. However, a company with 80 users in Office365 might have many hundreds on their Active Directory database. It’s probably not desirable to have all of those users synchronizing each time, so let’s restrict it down to just who you want.

  1. First, you’ll want to install the DirSync tool as normal. Download the installation from Office365 and save it somewhere. Then run the tool as an administrator. Enter your Office365 and local credentials, select Password Sync and proceed almost to the end – just don’t leave the Synchronize your directories now box checked as we’re going to customize it first.
  2. DirSync is built on the Forefront Identity Manager software – you’ll want to open the Synchronization Service Manager located  (on my machine) at C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe:
    DirSyncSetup1
  3. You may get the error Unable to connect to the Synchronization Service when you start this up. The key to resolving this is almost always Reason #2 – your account needs to be a member of the locally created FIMSyncAdmins group on this machine. Confirm that you are, and remember that you have to log back in for it to be effective:
    DirSyncSetup2
  4. Open the software and click the Management Agents section at the top. You’ll see two agents available – one for Active Directory and one for Windows Azure. Not surprisingly, the Active Directory agent interacts locally and the Windows Azure agent interacts with Office365. We’re going to customize the Active Directory connector by selecting it and then clicking the Properties action:
    DirSyncSetup3
  5. Here’s where life gets interesting … there are many places to customize this. What’s essentially happening here is that the Active Directory database is being dumped out to a local SQL installation, which then exports that data to the Windows Azure service. There are obviously many parts to this: Where does the data come from? What objects should be transferred? For those objects, what attributes? Should we filter those objects?
    We’re going to take advantage of that last question.
    In the Properties window that you last brought up, select Configure Connection Filter and then select the rules for the User object type:
    DirSyncSetup4
  6. Notice there are over a dozen rules for user objects alone – we’re filtering out some by sAMAccountName, others by the msExchRecipientType attribute. How you filter your users is up to you. For many of my setups, I’ve already got my two UPN suffixes, so I set people who should have an Office365 account to the public @example.com suffix and filter users who don’t have it. Note that you can have more than one condition per filter:
    DirSyncSetup6
  7. Once you click the OK button, your filter appears in the list. You can OK out of the rest of the boxes:
    DirSyncSetup7

If you want to test, you can run a full sync of the Active Directory connector by right-clicking it, selecting Run, and then running with the Full Import Full Sync profile. You’ll get statistics that will show you what was imported and kept:

DirSyncSetup8

Permissions of MachineKeys Folder on Server 2012

I just had a customer whose Exchange 2013 machine was acting … weird. There were issues with the OWA site loading, and some bizarre event log messages regarding SChannel errors. I began investigating these by opening the IIS console and looking at the bindings for HTTPS, which appeared good.

And then I clicked OK … the server slowed significantly (wrote thousands of messages to the event log), and then I received this message:

A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: [...])

At this moment, IIS went down. Knowing this message can happen because of a certificate validity issue, I checked the certificates console and found the certificates showed valid, with private keys in place. The event log yielded Schannel #36870 messages reading:

A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

Some quick Google-fu yielded the potential that my private keys were missing, or had some access issues. There are many articles out there to deal with this, such as this one at MSDN or this MS KB Article. But it’s a bit lacking for Server 2012. Here’s some stuff to know:

  • Some articles reference C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA, while others reference C:\Users\All Users\Application Data\Microsoft\Crypto\RSA. The one above references C:\ProgramData\Microsoft\Crypto\RSA. On Server 2012, these are all hard links to one another.
  • I had issues making this fix without first stopping the Cryptographic Services service first.
  • The article wants you to confirm that Administrators has Full Control of the MachineKeys folder, and that Everyone has the following individual permissions:
    – List Folder/Read Data, Read Attributes, Read Extended Attributes, Create Files/Write Data, Create Folders/Append Data, Write Attributes, Write Extended Attributes, Read Permissions
  • None of the articles discuss inheritance. In my case, I had every one of the permissions right, but the Applies To section was “This folder” only. It has to be This folder, subfolders and files.
  • I had to take ownership of the directory and all files within, because the files themselves had inheritance turned off.

After the above work, I restarted the service and found that I could re-bind the certificates in IIS.