Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
> 
Connect to FIM MA in an untrusted domain

Answered Connect to FIM MA in an untrusted domain

  • Wednesday, January 02, 2013 4:21 PM
     
     
    Sign In to Vote
    0

    Hi,

    I could use some help please. Here's the situation:

    Domain A hosts the Corporate AD (CORP)
    Domain B hosts an External AD (IAM) and the FIM Portal

    There is no trust between the domains.

    There is a sync engine in both domains.

    The client does not want to have the CORP AD MA hosted on the External (IAM) Sync Engine.

    We are trying to use an FIM MA on the Domain A (CORP) sync engine. I am using an IAM account that is the account specified during the portal installation as the FIM Sync Management Agent account.

    When I try to connect, I receive the error that "The credentials provided for accessing Forefront Identity Manager are invalid".
       - I have triple-checked that I am entering credentials correctly.
       - I can connect to SQL using these credentials via ODBC.
       - There are no problems connecting to the FIM portal via IE from the sync server in the CORP domain.
       - I could connect using these credentials when a trust was established, but the client does not want to create a trust just for this. [edit: when a trust is established, I can connect with a CORP account.]

    Is there something I am overlooking? It seems like a trust shouldn't be required if the management agent is using the credentials of the domain hosting SQL and the portal.

    Edit 2: Could it be that the FIM MA account needs to have log on locally permissions on the synchronization server? That's not possible without a trust if the portal and domain are in two separate forests. The FIM Sync account won't be able to impersonate the FIM MA account. Is this impersonation still needed for R2?

    I would appreciate any suggestions.

    Thanks,

    Sami




    • Edited by SamiVV Wednesday, January 02, 2013 9:55 PM
    •  
     

All Replies

  • Wednesday, January 02, 2013 9:53 PM
     
     Answered
    Sign In to Vote
    0
    yes, the account used in the FIM MA needs the �??Allow Logon Locally�?� user right on the server with the Sync Engine

    <o:p></o:p>

    Cheers,<o:p></o:p>


    (HOPEFULLY THIS INFORMATION HELPS YOU!)
    Jorge de Almeida Pinto | MVP Identity & Access - Directory Services

    -------------------------------------------------------------------------------------------------------
    * This posting is provided "AS IS" with no warranties and confers no rights!
    * Always evaluate/test yourself before using/implementing this!
    * DISCLAIMER:     http://jorgequestforknowledge.wordpress.com/disclaimer/
    -------------------------------------------------------------------------------------------------------
    ################# Jorge's Quest For Knowledge ###############
    ###### BLOG URL:     http://JorgeQuestForKnowledge.wordpress.com/ #####
    #### RSS Feed URL:     http://jorgequestforknowledge.wordpress.com/feed/ ####
    -------------------------------------------------------------------------------------------------------    <o:p></o:p>

    "SamiVV" wrote in message news:e607b9a9-90e3-423e-82fc-f89962435db1@communitybridge.codeplex.com...

    Hi,

    I could use some help please. Here's the situation:

    Domain A hosts the Corporate AD (CORP)
    Domain B hosts an External AD (IAM) and the FIM Portal

    There is no trust between the domains.

    There is a sync engine in both domains.

    The client does not want to have the CORP AD MA hosted on the External (IAM) Sync Engine.

    We are trying to use an FIM MA on the Domain A (CORP) sync engine. I am using an IAM account that is the account specified during the portal installation as the FIM Sync Management Agent account.

    When I try to connect, I receive the error that "The credentials provided for accessing Forefront Identity Manager are invalid".
       - I have triple-checked that I am entering credentials correctly.
       - I can connect to SQL using these credentials via ODBC.
       - There are no problems connecting to the FIM portal via IE from the sync server in the CORP domain.
       - I could connect using these credentials when a trust was established, but the client does not want to create a trust just for this. [edit: when a trust is established, I can connect with a CORP account.]

    Is there something I am overlooking? It seems like a trust shouldn't be required if the management agent is using the credentials of the domain hosting SQL and the portal.

    Edit 2: Could it be that the FIM MA account needs to have log on locally permissions on the synchronization server? That's not possible without a trust if the portal and domain are in two separate forests. The FIM Sync account won't be able to impersonate the FIM MA account. Is this imipersonation still needed for R2?

    I would appreciate any suggestions.

    Thanks,

    Sami



    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/
    • Marked As Answer by SamiVV Wednesday, January 02, 2013 9:56 PM
    •  
     
  • Wednesday, January 02, 2013 9:55 PM
     
     
    Sign In to Vote
    0

    Thanks, Jorge. I guess this means we have to have a trust in place. That's a pity since it will cause a lot of political issues.

    I appreciate your help.

     
  • Wednesday, January 02, 2013 10:16 PM
     
     
    Sign In to Vote
    0
    even if it would work without the trust and you were able to sync user through the sync engine in domain A to the portal in domain B, those user accounts from domain A would NOT be able to logon to the fim portal, even if you would sync the minimum required attributes to be able to logon (domain, samaccountname, objectsid). In addition to the minimum required attributes, the domain the fim portal exists in needs to trust the domain of the users that need to logon to the fim portal

    <o:p></o:p>

    Cheers,<o:p></o:p>


    (HOPEFULLY THIS INFORMATION HELPS YOU!)
    Jorge de Almeida Pinto | MVP Identity & Access - Directory Services

    -------------------------------------------------------------------------------------------------------
    * This posting is provided "AS IS" with no warranties and confers no rights!
    * Always evaluate/test yourself before using/implementing this!
    * DISCLAIMER:     http://jorgequestforknowledge.wordpress.com/disclaimer/
    -------------------------------------------------------------------------------------------------------
    ################# Jorge's Quest For Knowledge ###############
    ###### BLOG URL:     http://JorgeQuestForKnowledge.wordpress.com/ #####
    #### RSS Feed URL:     http://jorgequestforknowledge.wordpress.com/feed/ ####
    -------------------------------------------------------------------------------------------------------    <o:p></o:p>

    "SamiVV" wrote in message news:cedfd106-92fd-4a5f-904a-3111b050b337@communitybridge.codeplex.com...

    Thanks, Jorge. I guess this means we have to have a trust in place. That's a pity since it will cause a lot of political issues.

    I appreciate your help.

    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/
     
  • Wednesday, January 02, 2013 10:27 PM
     
     
    Sign In to Vote
    0

    Right. It's kind of a weird set up. We are mainly using the portal for group management. So, the internal users logging in may not be an issue. (We are still trying to determine that though. Just wanted to see what was possible.)

    With your help, I was able to connect using SQL Authentication when I added the a user with the same account name as the SQL user to the "Allow logon locally" permission.

    Many thanks for your time!

    Sami

     
  • Wednesday, January 02, 2013 10:32 PM
     
     
    Sign In to Vote
    0
    no problem. glad to be of help.
     
    by the way.... why does management of domain A not want the sync engine in domain B to connect to domain A and do what needs to be done? 

    Cheers,


    (HOPEFULLY THIS INFORMATION HELPS YOU!)
    Jorge de Almeida Pinto | MVP Identity & Access - Directory Services

    -------------------------------------------------------------------------------------------------------
    * This posting is provided "AS IS" with no warranties and confers no rights!
    * Always evaluate/test yourself before using/implementing this!
    * DISCLAIMER:     http://jorgequestforknowledge.wordpress.com/disclaimer/
    -------------------------------------------------------------------------------------------------------
    ################# Jorge's Quest For Knowledge ###############
    ###### BLOG URL:     http://JorgeQuestForKnowledge.wordpress.com/ #####
    #### RSS Feed URL:     http://jorgequestforknowledge.wordpress.com/feed/ ####
    -------------------------------------------------------------------------------------------------------    <o:p></o:p>

    "SamiVV" wrote in message news:ca346030-d024-471c-81e6-568ffafb299d@communitybridge.codeplex.com...

    Right. It's kind of a weird set up. We are mainly using the portal for group management. So, the internal users logging in may not be an issue. (We are still trying to determine that though. Just wanted to see what was possible.)

    With your help, I was able to connect using SQL Authentication when I added the a user with the same account name as the SQL user to the "Allow logon locally" permission.

    Many thanks for your time!

    Sami

    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/
     
  • Thursday, January 03, 2013 12:32 AM
     
     
    Sign In to Vote
    0

    I think it's more a matter of going through all of the bureaucracy to establish the trust. There's a bit of regulation and processes that could drag it out for a while.

    Thanks again!

    Sami