When migrating user or group objects with ADMT, one of the options is to update the user rights for the migrated objects. For me the ADMT help or migration guide have always been pretty unclear what this option in fact does.

If you grant a group or user user rights assignments like “act as part of the operating system” or “impersonate a client after logon” on the domain controllers in the source domain, then “update user rights” option in ADMT will ensure the migrated object will get these user rights assignments as well.

Picture of the source security policy on a DC:

The ADMT migration log saying that the privileges where granted. The seTcbPrivilege means “trusted computing base” privilege and is in fact “act as part of the operating system”.

And in the security policy of a domain controller in the target domain:

This is an option which I would rather not check during migrations. If some of the users or groups require these kind of privileges, I would set them by hand afterwards.

For my current project I wanted to ease some of the ADMT tasks by using an option file and as such avoid the GUI and its repeatedly point and clicks. So I ended up figuring out how to translate the checkboxes from the GUI to the option file equivalent. At first I thought figuring out what the exact options were would be hard. Not at all! A nice sample is given in the ADMT guide and every (I mean every) possible setting/value is explained in a help file located somewhere in the c:\windows\admt installation folder.

The ones which weren’t explained was the syntax for the “source ou” and “target ou”. One could think, how hard can that be?

• ou=users,ou=department,ou=resources,dc=source,dc=com
• ou=users,ou=department,ou=resources
• LDAP://source.com/ou=users,ou=department,ou=resources,dc=source,dc=com

Example error:

The migration log was stored in the database. The migration log can be retrieved from the database by using the 'ADMT TASK' command. Unable to migrate users. Unable to bind to container 'LDAP://targetdomain/OU=users,OU=_Migration,DC=target,DC=com'.  Unable to get distinguished name for 'target.com/LDAP://target.com/OU=users,OU=_Migration,DC=target,DC=com'.  : The parameter is incorrect. (0x80070057)

And a screenshot:

All my options were wrong, so I started google and stumbled upon this: GNT Forums: ADMT command line or vbscript syntax in OU

The required syntax is the following:

• drop the domain part from the DN
• provide the OU’s up to down in the domain tree
• separate OU’s by using “/” (not ou=,)

Example:

• “resources/department/users”

Now that wasn’t obvious to me…

Once the option file is completed, it can be used with the admt commandline tool: “admt user /f:users_to_migrate.txt /o:optionfile.txt”. This is merely and example, a lot of variations on this matter exist.

Another requirement for ADMT to start migrating SIDhistory is the “Audit Account Management” setting on both source and target domain DCs. This should be set to both success and failure. When the domain still has Windows 2003 domain controllers, then this is as easy as setting the following setting in the domain controllers GPO:

However when dealing with Windows 2008 (or 2008 R2) domain controllers, the new fine-grained auditing settings come in play. Setting the above might have no effect. See how the setting is managed by GPO, but the setting says “no auditing”:

The reason for this is the “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” (wow what a setting) which is enabled.

When this setting is active, we have to configure the auditing configuration through auditpol.exe (a built-in command line utility). Try using “auditpol /get/ category:*” to find out the current settings. Or use “auditpol /set /category:”Account Management” /success:enable /failure:enable”. In the end the Account Management category should look like:

Remember: the auditpol commands have to be executed on each domain controller! If you have the MS Enterprise Client model implemented, as referenced in my previous blog entry, you will have to edit the template auditing settings files in the sysvol folder which come with the EC accelerator.

A nice place to start when considering ADMT is the ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains The above requirement comes from this guide.

When users and groups are migrated using the Active Directory Migration Tool (ADMT), there is an option to copy the SID’s of the objects in the source domain to the target domain. The reason for this is to allow migrated users to access resources which are still located in the source domain, and hence are secured with SID’s of the source domain.

By default a trust doesn’t allows users to access resources by using SID’s from their SID history. This is security feature. When creating a trust the following message is shown:

SIDhistory can be temporarily enabled until all resources are migrated from the source domain. SID history should be enabled on the outgoing trust of the trusting domain. The following example will explain the roles of the domains in the commands:

• Source domain
  • contains the user & group objects before migration
  • contains the resources to be accessible during the migration
  • is called the “trusting” domain
• Target domain
  • contains the user & group objects after they are migrated
  • is called the “trusted” domain

Which command to use depends on the type of the trust:

• External trust: netdom trust trustingDomain /domain:trustedDomain /quarantine:no
• Forest trust: netdom trust trustingDomain /domain:trustedDomain /enableSIDhistory:yes

It might seem contradictory that one command requires yes and the other no, but in fact these both enable the use of SIDhistory across the trust. If you want to determine the current state, simply execute the command without the “:no” or “:yes” behind them. An example:

Depending from which side of the trust you launch this command, you might have to specify additional credentials, you can specify (optional) credentials for both the trusting and the trusted domain. The commandline options for netdom trust are explained at TechNet.

Today I received “access is denied” both at trying to enable SIDhistory or simply trying to determine the current setting.

The reason? "Network access: Allow anonymous SID/Name translation" has to be enabled on the domain controllers. This settings can be found in the domain controllers GPO’s (either the default or your custom ones) at "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options". On a Windows 2003 domain this is not disabled by default, but in my Windows 2008 R2 target domain, the Microsoft Enterprise Client security model is implemented and this disables the anonymous SID/Name translation. if you want additional information about this setting, check KB823659

I think it might actually be necessary to enable this when configuring or reading the current setting concerning the SIDhistory. I don’t think this has to be enabled for SIDhistory to actually work. If it does, I’ll post an update in the following weeks.

My source: sid-filtering access is denied

In the end all is fine:

I do not like it when a newly installed environment has event log entries with other than informational events, especially if these warnings are recurring. But I guess this one is an example which can be safely ignored. By design the KDC service periodically tries to locate a Certificate Authority to request a certificate. When no CA is present, warnings are logged.

The event: event id 29, source: Microsoft-Windows-Kerberos-Key-Distribution-Center

The Key Distribution Center (KDC) cannot find a suitable certificate to use for smart card logons, or the KDC certificate could not be verified. Smart card logon may not function correctly if this problem is not resolved. To correct this problem, either verify the existing KDC certificate using certutil.exe or enroll for a new KDC certificate.

Additional information KB967623

One of my favorite tools when troubleshooting is Wireshark. One of the drawbacks is that you have to install it on your server. If you're not really sure whether the windows firewall is bothering your or not, you can enable the logging feature of the Windows Firewall. You can choose to log either dropped packets, successful connections or both.

To enable the logging feature, choose the firewall configuration section in the servermanager and choose the profile for which you want to enable logging:

Enable both dropped packets and successful connections:

The log file will be saved to %systemroot%\system32\logfiles\firewal\pfirewall.log

Just like when using Wireshark, some form of filtering is easy, I like using the built-in command line utility "findstr". By executing "findstr /I "IPofServerTryingToGetIn" c:\windows\system32\logfiles\firewall\pfirewall.log" you get a nice clean summary of all dropped and successful connections. In this specific case the SQL Browser service was unreachable at UDP 1434.

In the past year I’ve become more and more interested and familiar with Kerberos authentication. While I’m not saying that you should “Kerberize” everything, I think everyone installing and configuring apps on the Windows platform should have a basic understanding of it.

Below is a decision-based workflow I created to counter some simple pitfalls. Although some of it might seem easy, it gets forgotten a lot. In the example a user is browsing a web-based application which is reachable at “webapp.contoso.com”. In fact this website is hosted on a server called web01.contoso.com.

Important to note that ending up in the orange field (“client uses NTLM”) isn’t necessarily bad, but it might be when your web app does some form of delegation afterwards. On the other hand, if you end up in the “authentication impossible”, you will never-ever get granted access to the application.

This example is based on a web-based application, but the reasoning is exactly the same when the IE browser is a SQL client and the application pool for the website is a SQL Server service.

Perhaps the most common one to be encountered is the one where someone uses a service account for an application pool instead of the network service. If you then try to access the website with the name of the machine, you will always end up in the “authentication impossible”.

Any feedback or comments is highly appreciated. The chart, click the picture for a clearer view:

Earlier I posted about FIM 2010 support for AD 2008 R2 and the fact that the updates were available by using windows updates or the update catalog: FIM 2010 update (KB978864) install issue

Seems like finally the official KB got through: Update Package 1 for Microsoft Forefront Identity Manager (FIM) 2010

I’m a bit disappointed about the details given. The explanation given by Markus Vilcinskas on TechNet forums: What’s New in FIM update 1 has some interesting extra information:

• A new prerequisite for Update 1: The FIM Synchronization Service is now using SQL Native Agent, so be sure to install it before you install the update
• FIM Synchronization Service changes:
• Added support for Recycle Bin in Active Directory.
  To get the correct result, install the Active Directory Recycle Bin fix 979214 on the DC used by FIM Synchronization Service.
• Added a new feature called “Resume Full Sync”.
  If a full sync is not completed the next time the same run profile is attempted a new option in Run Management Agent will allow the administrator to continue the Full Sync from the point that it stopped.
• Addressed an issue to detect Exchange Server 2010 in the AD MA.

In my opinion the update is really advised, especially if you’re using Exchange 2010 and/or Active Directory based on Windows 2008 R2

Since Windows 2008 there is a new well-known security principal called “Owner Rights”. In the past there were some scenario’s in a delegation situation which could be hard to solve. The following example is specific to Active Directory, but the same principle goes for file permissions.

One problem was the delegation of creating objects without being able to delete them. As the creator is also the owner of the object, he is able to alter the permissions of the object. Another was the situation in which someone gets removed from the groups granting permissions. Because that person originally created the objects and is in fact still listed as owner, he still can also change permissions. In both cases the original creator of the object is capable of granting him or herself full permissions on the objects. Below an example.

The following command allows the group “DL_GroupAdmins” to create groups in the groups OU.

• dsacls "ou=groups,ou=corp,dc=home,dc=local" /I:T /G "home\DL_GroupAdmins":CC;group

After creating a DL_Test group as a member of DL_GroupAdmins, we can clearly see our permissions are very limited (create group objects) and our user “deleg” is listed as owner:

Because our user is listed as owner of the group, he can change permissions to grant himself full control on the object. On the left is a picture showing he can control security, on the right is a screenshot of the general tab after giving himself full control.

And this is where “owner rights” comes in handy. Because the owner can always change permissions, we will redefine what an owner of an object can do. With the following command we will ensure owners of objects will only have generic read permissions.

• dsacls "ou=groups,ou=corp,dc=home,dc=local" /I:T /G "Owner Rights":GR

In my opinion a must: it is really easy to implement and it ensures permissions aren’t being tampered with.

Some colleagues and I have been investigating our options for performing GAL Sync between Exchange 5.5, Exchange 2007 and Exchange 2010 organizations. In the past their have been released several precedents of FIM which support GAL Sync:

Identity Integration Feature Pack SP2:

• download (October 2008)
• Free
• Supported connectivity:
  • Active Directory (AD), Active Directory Application Mode (ADAM)
  • Exchange 2000, Exchange 2003
• Step by step guide: Identity Integration Feature Pack (IIFP) - GalSync unleashed

Identity Lifecycle Manager 2007 Feature Pack 1 Service Pack 1:

• download (February 2007) and SP1 (March 2010)
• Supported connectivity:
  • AD 2000/2003/2003 R2/2008
  • ADAM 2003/2003 R2 and AD Lightweight Directory services (AD LDS) 2008
  • Exchange 5.5, 2000, 2003, 2007, 2010
• Step by step guide:Technet: Deploy Exchange 2010 in a Cross-Forest Topology

Remark: Exchange 2010 was initially not included and support was added in Service Pack 1: KB977791 and ILM 2007 SP1 … Exchange 2010 support

Forefront Identity Manager 2010:

• download (March 2010)
• Supported connectivity:
  • AD 2000, 2003, 2003 R2, 2008, 2008 R2
  • ADAM 2000/2003/2003 R2 & AD LDS 2008/2008 R2
  • Exchange 2000, 2003, 2007, 2010 (GAL Sync)

Remark: I initially tried combining GAL Sync management agents and other management agents (SQL, FIM Service, …) and that seemed to be a bad idea. I tried finding some feedback on this topic, but all in vain. However finally I got an answer:

It seems like the GAL Sync MA’s are really not designed and built to be able to co-exist with the other MA’s. They simply can’t handle the actions which are triggered by the FIM Service Ma or say a SQL MA. The GAL Sync MA has no idea how to handle ERE, DRE or Synchronization Rule projections. It would take a lot of work to alter the GAL Sync code to also support the FIM MA.

Shortly: If you want to use the built-in GAL Sync capabilities, install a separate FIM server for it.

Conclusion: If you need Exchange 5.5 in the GAL Sync, ILM 2007 FP1 SP1 seems your best bet. If you just need GAL Sync with Exchange 2000 and upwards, FIM will do.

A while a go I was wondering why Windows 2008 R2 wasn’t enlisted in the list of supported management agents for Active Directory services. This list can be found at http://www.microsoft.com/forefront/identitymanager/en/us/faq.aspx and now actually include Windows 2008 R2.
So I asked this over at the activedir.org mailing list and Thomas Onyszko came with the following answer on his blog “Tomek’s DS World”: FIM and Windows 2008 R2 AD support
Recently some updates were released for FIM (KB978864) which have up till now no associated KB article (still going through review I think) but yesterday Thomas posted an update on the subject: Windows 2008 R2 recycle bin support for FIM.
Bottom line:

• Install KB979214 on your DC’s
• Install KB978864 on your FIM servers, available through windows update or the update catalog
• Enable/Use recycle bin!

Setting up FIM with an SQL (HR data source), Active Directory and the FIM Portal (declarative provisioning) was more or less a quickie. I guess the OCG “FIM Foundation” training helped with that :)

But now I’m starting to add a GAL Sync to that lab setup and things are crumbling down. The first thing I was seeing was a lot of the “extension-dll-exception” messages when doing a sync for the FIM MA:

Those anchors (the identifier on the left in the picture) seemed to reference ExpectedRuleEntries being projected into the MV. Those EREs are caused by the synchronization rules I have configured in the portal. The GALSync.dll which is responsible for the provisioning is the one complaining:

Microsoft.MetadirectoryServices.NoSuchAttributeInObjectTypeException: Attribute "cn" is not usable with the object type in question.
   at Microsoft.MetadirectoryServices.Impl.EntryState.GetAttribute(String attributeName, IMacroCollectionBase collection)
   at Microsoft.MetadirectoryServices.GALSync.MVSynchronizer.AddOrRenameConnector(ConnectedMA& MA, GALMA& MAConfig, MVEntry mventry, CSEntry csentry)
   at Microsoft.MetadirectoryServices.GALSync.MVSynchronizer.Provision(MVEntry mventry)

I posted it out on the Technet forums for FIM and it seemed I had to alter the GALSync.dll its behavior. Everything which is being projected in the MV is being parsed by the GALSync.dll logic. By using a select case we can exclude certain object types.

We need the following items to rebuild the GALSync.dll:

• GALSync sources: C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\SourceCode\GalSync
• Logging.dll: C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Extensions
• Microsoft.MetadirectoryServicesEx.dll: C:\Program Files\Microsoft Forefront Identity Manager\2010\Service
• Visual Studio

After opening the solution in visual studio we get some errors:

These are due to the fact that my visual studio is not on the same box as the FIM Sync service is installed on. That’s why I said we would need the sources and dlls. We can add them to the project by right clicking the GALSync and choosing properties

Just click Add reference, choose browse and point to the DLLs (both the logging and MetadirectoryServicesEx one)

Now we are ready to alter the code as we wish:

Select Case mventry.ObjectType
    Case "expectedRuleEntry"
        ' Do Nothing
        Log(mventry.ToString & " is an expectedRuleEntry, no provisioning required")
    Case "synchronizationRule"
        ' Do Nothing
        Log(mventry.ToString & " is a synchronizationRule, no provisioning required")
    Case "detectedRuleEntry"
        ' Do Nothing
        Log(mventry.ToString & " is a detectedRuleEntry, no provisioning required")
    Case Else
        Dim i As Integer
        Dim MasterConnector As CSEntry = Nothing
        Dim MA As ConnectedMA
        Log("Entering provisioning for " & mventry.ToString)

        ...

End Select

Watch out: the Case string is case sensitive, ExpectedRuleEntry will not work. Minor e is required.

Many thanks to Jeremy Palenchar for providing the code.

I started toying with GAL Sync in FIM 2010 RTM and here are some mistakes I made. Perhaps somebody else might be making the same mistakes.

At first all users/contacts were appearing in the MV, but no exports were being proposed… This was due to the fact that I hadn’t enabled provisioning in the Sync Manager options:

The second problem I was seeing was a lot of users being added twice into the MV and eventually into my portal. This was because the already present AD MA didn’t synchronized any attributes which the GAL MA uses to join upon. Therefore I extended the GAL MA to also use the employeeID as a possible join attribute:

After cleaning the CS of the GAL MA and doing an import again, things started looking better!

In my lab environment I have been setting up two exchange servers. One in the forest in which the FIM services are located, and one in another forest. I want to play around with the built-in GAL Sync functionality.

Creating the MA for the forest the FIM services were in was no problem, however once I started creating the MA for the other forest I got the following error:

“The LDAP server is unavailable”. This seemed odd as in the previous step of the wizard I was able to successfully select the desired Organizational Units. If I ignored the error I was stuck with the wizard stating "It appears this forest is not exchange enabled”.

After installing the FIM 2010 first update, the error magically went away. I’m not sure it is because of the update, but it sure does like.

The FIM updates can be downloaded and installed from windows update.

Another person suffering the same issue: serverfault topic

This morning I read about two new updates for the FIM Synchronization and FIM Service services on Brad Turners Blog: FIM 2010 - Update 1 Released to Windows Update

So I went forward. The update for the Synchronization Service installed fine, but the update for the FIM Service started with the following error:

Error 25070.Error connecting to database FIMSynchronizationService. Invalid class string

It went on, but eventually rolled back the second update… I wanted to verify the Sync Service by opening the Synchronization Service Manager:

In my event log DCOM was becoming unhappy and was complaining for both the sync service account and my account.

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{835BEE60-8731-4159-8BFF-941301D76D05}
and APPID
{835BEE60-8731-4159-8BFF-941301D76D05}
to the user CORP\thomas SID (S-1-5-21-1739285864-795146598-2204218754-1104) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

The DCOM ID seems to be the “Forefront Identity Manager Synchronization Service”. Verifying it’s permissions I found out that the FIM groups (which the installer configured) were gone and replace by SID’s unknown to my domain.

My user his SID looks like:

After manually re-adding the groups it looked like this:

All I needed was a restart of the Forefront Identity Manager Synchronization Service and I could access the FIM Synchronization Manager again. Oef!

However the update wasn’t installed yet… So I tried again. Again the error popped up and my component services permissions screwed:

The funny thing is the SID’s now start at 1018… I have no clue what is going on. I have no time to go further on this. But I’m curious if there’s anyone out there experiencing the same.

[update] I posted this issue over at technet forums and Andreas Kjellman pointed me to the fact that if SQL is off-box from the Sync Engine, the Microsft SQL Server 2008 Native Client has to be installed. After installing the client the update went flawless.

A link to the client: SQL 2008 Native Client

I think it would be nice if they added this information to the Hardware and Software Requirements for FIM on technet.