FIM Service Management Agent Creation Error

I recently began building a FIM 2010 RC1 VM for testing/demo purposes.  This is an all-in-one Server 2008 machine, so in addition to FIM 2010, it has AD DS, Exchange 2007, SQL 2008, SharePoint Services, and Visual Studio 2008.

FIM 2010 recommends three FIM related user accounts:

• FIM Synchronization Engine
• FIM Service
• FIM Management Agent

I created the accounts and set up the Sync service without issue.  After installing the FIM portal and service, I went to set up the FIM Service Management Agent, but received the following error:

Failed to retrieve the schema.

Failed to connect to the specified database or Forefront Identity Manager Service. Please check the specified database location, service host address, and account information.

I double checked all of my information (and even re-installed the FIM Service to verify the settings I used when installing it), but nothing seemed to be wrong.  I enabled all success and failure auditing on the DC, and found the following event when I retried the information:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/13/2009 11:19:43 AM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      FIM.lab.loc
Description:
An account failed to log on.

Subject:
    Security ID:        LAB\FIM_sync
    Account Name:        FIM_sync
    Account Domain:        LAB
    Logon ID:        0x130e4c

Logon Type:            2

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:        FIM_ma
    Account Domain:        LAB

Failure Information:
    Failure Reason:        The user has not been granted the requested logon type at this machine.
    Status:            0xc000015b
    Sub Status:        0x0

Process Information:
    Caller Process ID:    0x168c
    Caller Process Name:    C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe

Network Information:
    Workstation Name:    FIM
    Source Network Address:    -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:        Advapi 
    Authentication Package:    Negotiate
    Transited Services:    -
    Package Name (NTLM only):    -
    Key Length:        0

Note the “The user has not been granted the requested logon type at this machine” message.  In my case, the server is a DC, so that account has no rights to log on.  Once I put the account into the domain local Administrators group, the MA creation process proceeded just fine.

Forefront Identity Manager (FIM) 2010 RC1 released

The long awaited RC1 for FIM 2010 was released yesterday.  Microsoft has promised an upgrade path from RC1 to RTM.  No upgrade path exists for any of the betas or RC0.

Get the bits at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4bb3f16b-27f8-4c1d-922f-2c7b522d9ad6.

Using Messenger accounts with non-Microsoft SMTP Domains in LCS/OCS With PIC

UPDATED 03.18.09:  This does not work correct with Office Communicator 2007 R2 RTM.  The workaround for this can be found here.  Also, the list of MS domains has expanded to include live.com and its variants.  See the KB article referenced below for the full list.

 

I'm not sure if the subject on this post even makes sense, but it's the best I could come up with.  Essentially the issue is that even though you have LCS or OCS set up with Public IM Connectivity (PIC) you can't add contacts that use MSN/Live Messenger unless they have a Microsoft SMTP domain for their account.  The valid MS domains (as of the latest update on the KB article) are:

• hotmail.co.jp
• hotmail.co.th
• hotmail.co.uk
• hotmail.com
• hotmail.com.ar
• hotmail.com.tr
• hotmail.de
• hotmail.it
• hotmail.fr
• messengeruser.com
• msn.com
• simpatico.ca
• passport.com
• passporthotmail.com
• webtv.com

I think it's safe to assume the live.com and all the country specific variations of it are on that list as well, but I haven't tested those.

But, you can set up a Messenger account with any SMTP domain you want.  If you add them in to the LCS/OCS client, they simply don't work.  I may be an idiot, but for the longest time I thought that's just the way it was.  Then today I stumbled across a KB article that describes how to do it.  It's a matter of manipulating the IM address of the contact you want to add.  It's not very obvious, and it would be nice to see the OCS client/server catch these and fix them for you, or at least tell you the proper format.

So I know user@gmail.com is a Messenger user, and I want to add them to my OCS client, the address should be entered in the following format:

user(gmail.com)@msn.com

Odd, but hey it works.  Check out the full KB article here.

The Fix is In! For the Exchange 2007 provisioning issue with ILM 2007 anyway…

Microsoft released the fix for the Exchange 2007 provisioning issue I blogged about earlier.  Essentially, Exchange didn’t properly use the domain controller parameter that was to the Update-recipient cmdlet, which in environments with multiple DCs would result in the mailbox not being properly provisioned because the DC in use by Update-Recipient didn’t know anything about the mailbox, as it was created on another DC.

Anyway, after a long wait (and a teaser release/un-release), Update Rollup 4 for Exchange Server 2007 SP1 has been re-released and contains the fix.  The KB article (949858) behind the specific issue is also public now.  Here are the details on the issue from the KB:

When ILM 2007 calls the Update-Recipient cmdlet to provision user objects, ILM 2007 passes a domain controller parameter to the Update-Recipient cmdlet to make sure that the task uses the same domain controller as the domain controller that was used where the object was created.

However, the Update-Recipient cmdlet creates two domain controller sessions. One session is for a domain controller, and the other session is for a global catalog server. The Update-Recipient cmdlet uses only the parameter that was passed for the global catalog server session, and it enables the Active Directory directory service driver to obtain a domain controller for the domain controller session. Then, the domain controller session is used for various operations, such as retrieving the properties of the object to pass to the Recipient Update Service.

If the domain controller that is selected for the domain controller session differs from the domain controller that is passed by ILM 2007, the Recipient Update Service object may not find the recipient. This issue occurs because of replication latency.

When this issue occurs, user objects may not be updated correctly by the Update-Recipient cmdlet. These objects are displayed as "mail users" instead of as "user mailboxes" in Exchange Management Console.

You can download Update Rollup 4 for Exchange Server 2007 SP1 here.

ISA 2006 and Slow LDAPS Authentication

I recently ran into an issue with LDAPS Authentication from ISA 2006 to an internal domain controller.  I am working with a client to deploy two ISA 2006 Enterprise Edition servers in their DMZ.  They have single NICs (NLB is enabled) and are not members of the internal domain, and are in their own workgroup (I know, I know, not an ideal use of ISA, but that’s a story for another time).  Because they are not in the domain, we decided to use LDAPS authentication (they already had an internal CA and certificates on all of their domain controllers).

Rules were added on the internal firewall rule to allow the ISA servers to do CRL checking to the internal CA and LDAPS traffic (port 636) to the domain controllers.  On the outside firewall, a rule was created to allow the ISA servers internet access for external CRL checking (this was needed to validate the third-party CA certificates in use on the published web servers when making the SSL connection from ISA to the web servers).

Once the rules were in place, the setup of LDAPS on the web listener was straightforward and it worked – sort of.  The initial login took about 15-20 seconds.  Subsequent logins were immediate, until LDAPS session were idle for too long, then the next login took 15-20 seconds again.

It was discovered that the internally issued certificates had both an Active Directory and HTTP CRL Distribution Point, and that AD was listed first.  The theory was the ISA was attempting to pull the CRL from AD first and failing, before succeeding in pulling the HTTP published version.

A coworker helped me find a series of registry keys that control CRL checking at the computer level.  Most of the CRL checking settings found out there though a good old Google search are for a specific user or IIS related, neither of which is applicable in the ISA LDAPS scenario, as the connection is not established under any specific user context and IIS is not involved at all for the LDAPS session.

According to the information, the default timeout value when processing a CRL is 15 seconds, which would explain the 15-20 seconds logons from ISA perfectly.  I added the following registry key to both ISA servers, rebooted them, and now the initial logins take 2-3 seconds.  Note that the value specified is in milliseconds and that the HEX value 000003e8 is equivalent to 1000 in decimal (1 second).

Location	HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
Type	REG_DWORD
Name	ChainUrlRetrievalTimeoutMilliseconds
Value	000003e8

 

Also note that if this value is set to 0 or if this value is undefined, the default value that is used is 15000 milliseconds.  It also doesn’t work if you spell retrieval wrong the first time like I did…