none
Extensible MA is Using FIM SynchService account instead of "connect" and "user" settings in MA configuration RRS feed

  • Question

  • We have been using a standard set of AD and ADAM Extensible Managed Agents in MIIS / ILM over the last 8 years and now that I have migrated our entire environment to FIM2010, the only issue I have left to solve is connectivity to AD in 1 ECMA.

    Our code is simple and I can see the .connect and .user variables being populated for connection to the AD Domain container but when the MA is run under FIM alone, it uses the FIM synch service to attempt the bind to AD rather than the account and password configured in the MA manager. I have refreshed it and even recreated it manually with the same result.

    I have the latest updates installed, checked all of the published issues with no problems and all of my standard AD MAs (36 on 3 synch servers) are working fine with the same account.

    Has anyone encountered this yet? I can hardcode the credentials into my ECMA DLL but I doubt that will work given the way it is running now, and I hate to embed IdM data in code.

    Thanks

    Mike Welborn

     

     

    Friday, June 15, 2012 6:40 PM

All replies

  • Mike-

    What does the code that's making the actual LDAP connection in your XMA look like?


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Friday, June 15, 2012 6:46 PM
    Moderator
  • I had to remove the proprietary naming of some of the objects. The actual bind is done by using the normal Dierctory Entry instantiation. The hasError variable gets set and I catch the exception. I also log the errors by using the ex.Message within the try section from another class. The VS 2010 code is compiled to refer to the Framework 4 DLLs on the server. 

    ...................................................................................................................................................................................

    Imports System.DirectoryServices
    Imports System.Text

    Public Class MyData
        Dim ADObject As DirectoryEntry          ' is the AD object
        Dim Data As PropertyValueCollection
        Public isDirty As Boolean               ' true if object was changed
        Public lastError As String              ' contains the last error
        Public hasData As Boolean
        Public hasError As Boolean = False
        ' creates a new instance
        ' ADObject holds the directory object
        Sub New(ByVal ADPath As String)
            hasData = False                                                 ' init the hasdata flag
            Try                                                             ' try to open/read AD object
                ADObject = New DirectoryEntry(ADPath)                       '   get a new userobject
                If ADObject.Properties.Contains("MyAttribute") Then     '   if siemens-CATData attribute of the AD object has data
                    Data = ADObject.Properties.Item("MyAttribute")      '   remember the data
                    hasData = True                                          '   set the hasData flag
                End If
            Catch ex As Exception                                           ' exception handling
                lastError = ex.Message                                      '   save error
                hasData = False                                             '   reset hasData flag
                hasError = True                                             '   set error flag
            End Try
        End Sub

    Friday, June 15, 2012 7:16 PM
  • Are you impersonating anywhere? If not, you're never passing the creds from the XMA to the DirectoryEntry constructor so it will run in the context of the sync engine.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Friday, June 15, 2012 7:18 PM
    Moderator
  • No, we use the generic ECMA IMV Class attributes that pass the Domain, account and passord to the DLL so impersonation in not needed. At least not until now. The ECMA framework code has always been able to pass the MA configuraton values to our DLL with no problems. It's a plain vanilla IMV interface .....

    The m_domain, m_username and m_password attributes are passed from the MA configuration to the extension DLL and authentication is set.

    Imports Microsoft.MetadirectoryServices
    Imports System.IO
    Imports System
    Imports System.Data
    Imports System.Data.SqlClient

    Public Class MydataExport
        Implements IMAExtensibleFileImport, IMAExtensibleCallExport
        ' constants
        ' variables
        Private m_commandPath, m_logFile As String
        Private m_UserName As String
        Private m_Domain As String
        Private m_Password As String
        Private m_DC As String
        Private m_FilePath As String
        'Private swOut As StreamWriter
        Private fileName As String = "MyFile.txt"
        Private ConnectDB As String                                    ' value of database
        Private ConnectServer As String
        Private ConnectTable As String
        Private ConnectEnabled As Boolean

    Friday, June 15, 2012 7:27 PM
  • You're never passing them to the constructor on your DirectoryEntry though. There's no possible way from what you've pasted that the S.DS calls have any clue about the creds provided to the XMA.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Friday, June 15, 2012 7:28 PM
    Moderator
  • The code is simple but there is a lot of it!

    I have an overloaded NEW Class that passes these for the impersonation ... I sent you the wrong sub last time.

    The ADPath are used together withe theusername and password for each bind.

    I will take a look at the running code again on the ILM servers that are working again and let you know if I find it.

    Thanks for the replies Brian!

     

       Sub New(ByVal ADPath As String, ByVal username As String, ByVal password As String)
            hasData = False                                                 ' init the hasdata flag
            Try                                                             ' try to open/read AD object
                ADObject = New DirectoryEntry(ADPath, username, password)                       '   get a new userobject
                If ADObject.Properties.Contains("MyData") Then     '   if siemens-CATData attribute of the AD object has data
                    Data = ADObject.Properties.Item("MyData")      '   remember the data
                    hasData = True                                          '   set the hasData flag
                End If
            Catch ex As Exception                                           ' exception handling
                lastError = ex.Message                                      '   save error
                hasData = False                                             '   reset hasData flag
                hasError = True                                             '   set error flag
            End Try
        End Sub

    Friday, June 15, 2012 8:46 PM
  • That new sample appears accurate. I would go through and check all your writes to ADObject and make sure you're never reinitializing it. You could mark the field readonly and that would negate the ability to reinitialize it.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Friday, June 15, 2012 8:50 PM
    Moderator