locked
Centralized Forest Model with OCS enabled contacts RRS feed

  • Question



  • Our objective is to enable users from different forests to utilize contact objects in the central/resource forest for instant messaging services using OCS.  We have delayed deploying LCS, choosing instead to wait for OCS.   The contacts from 20 different Active Directories already exist in the central forest via an existing LDAP synchronization tool --not Microsoft Identity Integration Services (MIIS)-- that we prefer not to replace because that would be a big project all by itself .    Microsoft indicates in the white papers for OCS that MIIS is a prerequisite for achieving what we want to do.  Is that the case, or is there any way to accomplish this without MIIS in place?

     

    In early testing populating the requisite fields on the contact objects from the associated users allows us to successfully enable the contacts for IM, but the users in the trusted AD cannot login to Communicator with Kerberos/NTLM (default) for authentication. 

     

    Friday, April 27, 2007 2:26 PM

Answers

  • MIIS is not a requirement, it's just the only way that Microsoft has documented.  Any decent directory synchronization tool should be able to meet your needs, or you can even script the necessary attribute modifications.  What you'll need to do is copy the objectSid attribute from the user's enabled account in their logon domain to the MSRTCSIP-OriginatorSid attribute on the contact object in the central forest.  When the user logs on to Communicator the OCS server will verify that the credentials match the SID in the source domain, so you'll need to make sure to have at least a one way trust in place.


    Z

    Friday, April 27, 2007 5:21 PM
    Moderator

All replies

  • MIIS is not a requirement, it's just the only way that Microsoft has documented.  Any decent directory synchronization tool should be able to meet your needs, or you can even script the necessary attribute modifications.  What you'll need to do is copy the objectSid attribute from the user's enabled account in their logon domain to the MSRTCSIP-OriginatorSid attribute on the contact object in the central forest.  When the user logs on to Communicator the OCS server will verify that the credentials match the SID in the source domain, so you'll need to make sure to have at least a one way trust in place.


    Z

    Friday, April 27, 2007 5:21 PM
    Moderator
  • We have this working great with a one-way or bidirectional, non-transitive trust in a multi-domain forest with selective authentication which is more secure.  Contact objects linked/mapped with MSRTCSIP-OriginatorSID on contact to the SID on the the users in the remote forest can be enabled for IM and have SSO.  NTLM was the only authentication protocol that would work --no Kerberos.  MIIS is not required, so any way to copy the data from the user account attributes to the contact objects in the resource forest works.  ADSIedit worked fine using copy/paste for quick testing.   
    Friday, June 1, 2007 2:34 AM